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Use this guide to configure, monitor, and troubleshoot the OSPF routing protocol on your Juniper Network 
devices. 


Junos OS Routing Protocols Library for Routing Devices 


Documentation and Release Notes 


To obtain the most current version of all Juniper Networks” technical documentation, see the product 


documentation page on the Juniper Networks website at https://www.juniper.net/documentation/. 


If the information in the latest release notes differs from the information in the documentation, follow the 
product Release Notes. 


Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts. 
These books go beyond the technical documentation to explore the nuances of network architecture, 
deployment, and administration. The current list can be viewed at https://www.juniper.net/books. 


Using the Examples in This Manual 


If you want to use the examples in this manual, you can use the load merge or the load merge relative 
command. These commands cause the software to merge the incoming configuration into the current 
candidate configuration. The example does not become active until you commit the candidate configuration. 


If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example 
is a full example. In this case, use the load merge command. 
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If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In 
this case, use the load merge relative command. These procedures are described in the following sections. 


Merging a Full Example 


To merge a full example, follow these steps: 


1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save the 
file with a name, and copy the file to a directory on your routing platform. 


For example, copy the following configuration to a file and name the file ex-script.conf. Copy the 
ex-script.conf file to the /var/tmp directory on your routing platform. 


system { 
scripts { 
commit { 
file ex-script.xsl; 


} 
interfaces { 
fxpO { 
disable; 
unit O { 
family inet { 
address 10.0.0.1/24; 


2. Merge the contents of the file into your routing platform configuration by issuing the load merge 


configuration mode command: 


[edit] 
user@host# load merge /var/tmp/ex-script.conf 


load complete 
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Merging a Snippet 


To merge a snippet, follow these steps: 


1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save the 
file with a name, and copy the file to a directory on your routing platform. 


For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the 
ex-script-snippet.conf file to the /var/tmp directory on your routing platform. 


commit { 
file ex-script-snippet.xsl; } 


2. Move to the hierarchy level that is relevant for this snippet by issuing the following configuration mode 
command: 
[edit] 


user@host# edit system scripts 
[edit system scripts] 


3. Merge the contents of the file into your routing platform configuration by issuing the load merge 
relative configuration mode command: 


[edit system scripts] 
user@host# load merge relative /var/tmp/ex-script-snippet.conf 
load complete 


For more information about the load command, see CLI Explorer. 
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Table 1 on page xviii defines notice icons used in this guide. 


Table 1: Notice Icons 


Meaning 


Informational note 


Caution 


Warning 


Laser warning 


Tip 


Best practice 


oO > > > @: 


Description 


xviii 


Indicates important features or instructions. 


Indicates a situation that might result in loss of data or hardware 


damage. 


Alerts you to the risk of personal injury or death. 


Alerts you to the risk of personal injury from a laser. 


Indicates helpful information. 


Alerts you to a recommended use or implementation. 


Table 2 on page xviii defines the text and syntax conventions used in this guide. 


Table 2: Text and Syntax Conventions 


Convention 


Bold text like this 


Fixed-width text like this 


Italic text like this 


Description 


Represents text that you type. 


Represents output that appears on 
the terminal screen. 


e Introduces or emphasizes important 


new terms. 
e Identifies guide names. 


e Identifies RFC and Internet draft 
titles. 


Examples 


To enter configuration mode, type 
the configure command: 


user@host> configure 


user@host> show chassis alarms 


No alarms currently active 


e A policy term is a named structure 
that defines match conditions and 
actions. 


e Junos OS CLI User Guide 


e RFC 1997, BGP Communities 
Attribute 


Table 2: Text and Syntax Conventions (continued) 


Convention 


Italic text like this 


Text like this 


< > (angle brackets) 


| (pipe symbol) 


# (pound sign) 


[ ] (square brackets) 


Indention and braces ( { }) 


; (semicolon) 


GUI Conventions 


Description 


Represents variables (options for 
which you substitute a value) in 
commands or configuration 
statements. 


Represents names of configuration 
statements, commands, files, and 
directories; configuration hierarchy 
levels; or labels on routing platform 
components. 


Encloses optional keywords or 
variables. 


Indicates a choice between the 
mutually exclusive keywords or 
variables on either side of the symbol. 
The set of choices is often enclosed 
in parentheses for clarity. 


Indicates a comment specified on the 
same line as the configuration 
statement to which it applies. 


Encloses a variable for which you can 
substitute one or more values. 


Identifies a level in the configuration 
hierarchy. 


Identifies a leaf statement at a 
configuration hierarchy level. 
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Examples 


Configure the machine’s domain 


name: 


[edit] 
root@# set system domain-name 
domain-name 


e Toconfigure a stub area, include 
the stub statement at the [edit 
protocols ospf area area-id] 
hierarchy level. 


e The console port is labeled 
CONSOLE. 


stub <default-metric metric>; 


broadcast | multicast 


(string1 | string2 | string3) 


rsvp { # Required for dynamic MPLS 
only 


community name members [ 
community-ids ] 


[edit] 
routing-options { 
static { 
route default { 
nexthop address; 
retain; 


Table 2: Text and Syntax Conventions (continued) 


Convention 


Bold text like this 


> (bold right angle bracket) 


Description 


Represents graphical user interface 
(GUI) items you click or select. 


Separates levels in a hierarchy of 


menu selections. 
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Examples 


e Inthe Logical Interfaces box, select 
All Interfaces. 

e Tocancel the configuration, click 
Cancel. 


In the configuration editor hierarchy, 
select Protocols>Ospf. 


We encourage you to provide feedback so that we can improve our documentation. You can use either 


of the following methods: 


e Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the Juniper 
Networks TechLibrary site, and do one of the following: 


ga Feedback - 


Is this page helpful? 


e Click the thumbs-up icon if the information on the page was helpful to you. 


e Click the thumbs-down icon if the information on the page was not helpful to you or if you have 
suggestions for improvement, and use the pop-up form to provide feedback. 


e E-mail—Send your comments to techpubs-comments@juniper.net. Include the document or topic name, 
URL or page number, and software version (if applicable). 


| Requesting Technical Support 


Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). 
If you are a customer with an active Juniper Care or Partner Support Services support contract, or are 


xxi 


covered under warranty, and need post-sales technical support, you can access our tools and resources 
online or open a case with JTAC. 


e JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User 
Guide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf. 


e Product warranties—For product warranty information, visit https://www.juniper.net/support/warranty/. 


e JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week, 
365 days a year. 


Self-Help Online Tools and Resources 


For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called 
the Customer Support Center (CSC) that provides you with the following features: 


Find CSC offerings: https://www.juniper.net/customers/support/ 


Search for known bugs: https://prsearch.juniper.net/ 


Find product documentation: https://www.juniper.net/documentation/ 


Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/ 


Download the latest versions of software and review release notes: 


https://www.juniper.net/customers/csc/software/ 


Search technical bulletins for relevant hardware and software notifications: 
https://kb.juniper.net/InfoCenter/ 


e Join and participate in the Juniper Networks Community Forum: 
https://www.juniper.net/company/communities/ 


e Create a service request online: https://myjuniper.juniper.net 
To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: 


https://entitlementsearch.juniper.net/entitlementsearch/ 


Creating a Service Request with JTAC 


You can create a service request with JTAC on the Web or by telephone. 
e Visit https://myjuniper.juniper.net. 
e Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico). 


For international or direct-dial options in countries without toll-free numbers, see 
https://support.juniper.net/support/requesting-support/. 
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OSPF is an interior gateway protocol (IGP) that routes packets within a single autonomous system (AS). 
OSPF uses link-state information to make routing decisions, making route calculations using the 
shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Each router running OSPF 
floods link-state advertisements throughout the AS or area that contain information about that router's 
attached interfaces and routing metrics. Each router uses the information in these link-state advertisements 
to calculate the least cost path to each network and create a routing table for the protocol. 


Junos OS supports OSPF version 2 (OSPFv2) and OSPF version 3 (OSPF v3), including virtual links, stub 
areas, and for OSPF v2, authentication. Junos OS does not support type-of-service (ToS) routing. 


OSPF was designed for the Transmission Control Protocol/Internet Protocol (TCP/IP) environment and 
as a result explicitly supports IP subnetting and the tagging of externally derived routing information. OSPF 
also provides for the authentication of routing updates. 


OSPF routes IP packets based solely on the destination IP address contained in the IP packet header. OSPF 
quickly detects topological changes, such as when router interfaces become unavailable, and calculates 
new loop-free routes quickly and with a minimum of routing overhead traffic. 


NOTE: On SRX Series devices, when only one link-protection is configured under the OSPF 
interface, the device does not install an alternative route in the forwarding table. When the 
per-packet load-balancing is enabled as a workaround, the device does not observe both the 
OSPF metric and sending the traffic through both the interfaces. 


An OSPF AS can consist of a single area, or it can be subdivided into multiple areas. In a single-area OSPF 
network topology, each router maintains a database that describes the topology of the AS. Link-state 
information for each router is flooded throughout the AS. In a multiarea OSPF topology, each router 
maintains a database that describes the topology of its area, and link-state information for each router is 
flooded throughout that area. All routers maintain summarized topologies of other areas within an AS. 
Within each area, OSPF routers have identical topological databases. When the AS or area topology 
changes, OSPF ensures that the contents of all routers’ topological databases converge quickly. 


All OSPFv2 protocol exchanges can be authenticated. OSPFv3 relies on IPsec to provide this functionality. 
This means that only trusted routers can participate in the AS’s routing. A variety of authentication schemes 
can be used. A single authentication scheme is configured for each area, which enables some areas to use 
stricter authentication than others. 


Externally derived routing data (for example, routes learned from BGP) is passed transparently throughout 
the AS. This externally derived data is kept separate from the OSPF link-state data. Each external route 
can be tagged by the advertising router, enabling the passing of additional information between routers 
on the boundaries of the AS. 


NOTE: By default, Junos OS is compatible with RFC 1583, OSPF Version 2. In Junos OS Release 8.5 
and later, you can disable compatibility with RFC 1583 by including the no-rfc-1583 statement. 
For more information, see “Example: Disabling OSPFv2 Compatibility with RFC 1583” on page 239. 


This topic describes the following information: 


OSPF Default Route Preference Values 


The Junos OS routing protocol process assigns a default preference value to each route that the routing 
table receives. The default value depends on the source of the route. The preference value is from O 
through 4,294,967,295 (232 - 1), with a lower value indicating a more preferred route. Table 3 on page 25 
lists the default preference values for OSPF. 


Table 3: Default Route Preference Values for OSPF 


How Route Is Learned Default Preference Statement to Modify Default Preference 
OSPF internal route 10 OSPF preference 
OSPF AS external routes 150 OSPF external-preference 

OSPF Routing Algorithm 


OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine 
the route to each destination. All routing devices in an area run this algorithm in parallel, storing the results 
in their individual topological databases. Routing devices with interfaces to multiple areas run multiple 
copies of the algorithm. This section provides a brief summary of how the SPF algorithm works. 


When a routing device starts, it initializes OSPF and waits for indications from lower-level protocols that 
the router interfaces are functional. The routing device then uses the OSPF hello protocol to acquire 
neighbors, by sending hello packets to its neighbors and receiving their hello packets. 


On broadcast or nonbroadcast multiaccess networks (physical networks that support the attachment of 
more than two routing devices), the OSPF hello protocol elects a designated router for the network. This 
routing device is responsible for sending link-state advertisements (LSAs) that describe the network, which 
reduces the amount of network traffic and the size of the routing devices’ topological databases. 


The routing device then attempts to form adjacencies with some of its newly acquired neighbors. (On 
multiaccess networks, only the designated router and backup designated router form adjacencies with 
other routing devices.) Adjacencies determine the distribution of routing protocol packets. Routing protocol 
packets are sent and received only on adjacencies, and topological database updates are sent only along 
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adjacencies. When adjacencies have been established, pairs of adjacent routers synchronize their topological 
databases. 


A routing device sends LSA packets to advertise its state periodically and when its state changes. These 
packets include information about the routing device’s adjacencies, which allows detection of nonoperational 
routing devices. 


Using a reliable algorithm, the routing device floods LSAs throughout the area, which ensures that all 
routing devices in an area have exactly the same topological database. Each routing device uses the 
information in its topological database to calculate a shortest-path tree, with itself as the root. The routing 
device then uses this tree to route network traffic. 


The description of the SPF algorithm up to this point has explained how the algorithm works within a single 
area (intra-area routing). For internal routers to be able to route to destinations outside the area (interarea 
routing), the area border routers must inject additional routing information into the area. Because the area 
border routers are connected to the backbone, they have access to complete topological data about the 
backbone. The area border routers use this information to calculate paths to all destinations outside its 
area and then advertise these paths to the area’s internal routers. 


Autonomous system (AS) boundary routers flood information about external autonomous systems 
throughout the AS, except to stub areas. Area border routers are responsible for advertising the paths to 
all AS boundary routers. 


OSPF Three-Way Handshake 


OSPF creates a topology map by flooding LSAs across OSPF-enabled links. LSAs announce the presence 
of OSPF-enabled interfaces to adjacent OSPF interfaces. The exchange of LSAs establishes bidirectional 
connectivity between all adjacent OSPF interfaces (neighbors) using a three-way handshake, as shown in 
Figure 1 on page 26. 


Figure 1: OSPF Three-Way Handshake 
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In Figure 1 on page 26, Router A sends hello packets out all its OSPF-enabled interfaces when it comes 
online. Router B receives the packet, which establishes that Router B can receive traffic from Router A. 
Router B generates a response to Router A to acknowledge receipt of the hello packet. When Router A 
receives the response, it establishes that Router B can receive traffic from Router A. Router A then generates 
a final response packet to inform Router B that Router A can receive traffic from Router B. This three-way 
handshake ensures bidirectional connectivity. 
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As new neighbors are added to the network or existing neighbors lose connectivity, the adjacencies in the 
topology map are modified accordingly through the exchange (or absence) of LSAs. These LSAs advertise 
only the incremental changes in the network, which helps minimize the amount of OSPF traffic on the 

network. The adjacencies are shared and used to create the network topology in the topological database. 


OSPF Version 3 


OSPFv3 is a modified version of OSPF that supports IP version 6 (IPv6) addressing. OSPFv3 differs from 
OSPF v2 in the following ways: 


e All neighbor ID information is based on a 32-bit router ID. 
e The protocol runs per link rather than per subnet. 
e Router and network link-state advertisements (LSAs) do not carry prefix information. 
e Two new LSA types are included: link-LSA and intra-area-prefix-LSA. 
e Flooding scopes are as follows: 
e Link-local 
e Area 


e AS 


e Link-local addresses are used for all neighbor exchanges except virtual links. 
e Authentication is removed. The IPvé authentication header relies on the IP layer. 
e The packet format has changed as follows: 

e Version number 2 is now version number 3. 

e The db option field has been expanded to 24 bits. 

e Authentication information has been removed. 

e Hello messages do not have address information. 


e Two new option bits are included: R and V6. 


e Type 3 summary LSAs have been renamed inter-area-prefix-LSAs. 


e Type 4 summary LSAs have been renamed inter-area-router-LSAs. 


SEE ALSO 


Understanding OSPF Areas and Backbone Areas | 74 
Example: Disabling OSPFv2 Compatibility with RFC 1583 | 239 


| OSPF Packets Overview 


IN THIS SECTION 


OSPF Packet Header | 28 

Hello Packets | 29 

Database Description Packets | 29 
Link-State Request Packets | 29 
Link-State Update Packets | 29 
Link-State Acknowledgment Packets | 30 


Link-State Advertisement Packet Types | 30 


There are several types of link-state advertisement (LSA) packets. 


This topic describes the following information: 


OSPF Packet Header 


All OSPFv2 packets have a common 24-byte header, and OSPFv3 packets have a common 16-byte header, 
that contains all information necessary to determine whether OSPF should accept the packet. The header 
consists of the following fields: 


e Version number—The current OSPF version number. This can be either 2 or 3. 
e Type—Type of OSPF packet. 

e Packet length—Length of the packet, in bytes, including the header. 

e Router ID—IP address of the router from which the packet originated. 


e Area ID—Identifier of the area in which the packet is traveling. Each OSPF packet is associated with a 
single area. Packets traveling over a virtual link are labeled with the backbone area ID, 0.0.0.0. . 


e Checksum—Fletcher checksum. 
e Authentication—(OSPFv2 only) Authentication scheme and authentication information. 


e Instance ID—(OSPFv3 only) Identifier used when there are multiple OSPFv3 realms configured on a link. 
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Hello Packets 


Routers periodically send hello packets on all interfaces, including virtual links, to establish and maintain 
neighbor relationships. Hello packets are multicast on physical networks that have a multicast or broadcast 
capability, which enables dynamic discovery of neighboring routers. (On nonbroadcast networks, dynamic 
neighbor discovery is not possible, so you must configure all neighbors statically as described in “Example: 
Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network” on page 51.) 


Hello packets consist of the OSPF header plus the following fields: 


Network mask—(OSPFv2 only) Network mask associated with the interface. 


Hello interval—How often the router sends hello packets. All routers on a shared network must use the 


same hello interval. 


Options—Optional capabilities of the router. 


Router priority—The router’s priority to become the designated router. 


Router dead interval—How long the router waits without receiving any OSPF packets from a router 


before declaring that router to be down. All routers on a shared network must use the same router dead 
interval. 


Designated router—IP address of the designated router. 


Backup designated router—IP address of the backup designated router. 


Neighbor—IP addresses of the routers from which valid hello packets have been received within the 
time specified by the router dead interval. 


Database Description Packets 
When initializing an adjacency, OSPF exchanges database description packets, which describe the contents 


of the topological database. These packets consist of the OSPF header, packet sequence number, and the 
link-state advertisement’s header. 


Link-State Request Packets 
When a router detects that portions of its topological database are out of date, it sends a link-state request 


packet to a neighbor requesting a precise instance of the database. These packets consist of the OSPF 
header plus fields that uniquely identify the database information that the router is seeking. 


Link-State Update Packets 


Link-state update packets carry one or more link-state advertisements one hop farther from their origin. 
The router multicasts (floods) these packets on physical networks that support multicast or broadcast 
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mode. The router acknowledges all link-state update packets and, if retransmission is necessary, sends the 
retransmitted advertisements unicast. 


Link-state update packets consist of the OSPF header plus the following fields: 


e Number of advertisements—Number of link-state advertisements included in this packet. 


e Link-state advertisements—The link-state advertisements themselves. 
Link-State Acknowledgment Packets 
The router sends link-state acknowledgment packets in response to link-state update packets to verify 


that the update packets have been received successfully. A single acknowledgment packet can include 
responses to multiple update packets. 


Link-state acknowledgment packets consist of the OSPF header plus the link-state advertisement header. 


Link-State Advertisement Packet Types 


Link-state request, link-state update, and link-state acknowledgment packets are used to reliably flood 
link-state advertisement packets. OSPF sends the following types of link-state advertisements: 


Router link advertisements—Are sent by all routers to describe the state and cost of the router’s links 
to the area. These link-state advertisements are flooded throughout a single area only. 


Network link advertisements—Are sent by designated routers to describe all the routers attached to the 


network. These link-state advertisements are flooded throughout a single area only. 


Summary link advertisements—Are sent by area border routers to describe the routes that they know 


about in other areas. There are two types of summary link advertisements: those used when the 
destination is an IP network, and those used when the destination is an AS boundary router. Summary 
link advertisements describe interarea routes, that is, routes to destinations outside the area but within 
the AS. These link-state advertisements are flooded throughout the advertisement’s associated areas. 


AS external link advertisement—Are sent by AS boundary routers to describe external routes that they 


know about. These link-state advertisements are flooded throughout the AS (except for stub areas). 


Each link-state advertisement type describes a portion of the OSPF routing domain. All link-state 
advertisements are flooded throughout the AS. 


Each link-state advertisement packet begins with a common 20-byte header. 


SEE ALSO 


Understanding OSPF Areas | 65 
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Understanding OSPF Configurations | 35 
OSPF Designated Router Overview | 68 
Understanding OSPFv2 Authentication | 246 
OSPF Timers Overview | 282 


| Understanding OSPF External Metrics 


When OSPF exports route information from external autonomous systems (ASs), it includes a cost, or 
external metric, in the route. OSPF supports two types of external metrics: Type 1 and Type 2. The difference 
between the two metrics is how OSPF calculates the cost of the route. 


e Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the 
internal costs plus the external cost. This means that Type 1 external metrics include the external cost 
to the destination as well as the cost (metric) to reach the AS boundary router. 


e Type 2 external metrics are greater than the cost of any path internal to the AS. Type 2 external metrics 
use only the external cost to the destination and ignore the cost (metric) to reach the AS boundary router. 


By default, OSPF uses the Type 2 external metric. 


Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 
external metrics always takes the precedence. 


Type 1 external paths are always preferred over Type 2 external paths. When all paths are Type 2 external 
paths, the paths with the smallest advertised Type 2 metric are always preferred. 


SEE ALSO 


| Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217 


| Supported OSPF and OSPFv3 Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for OSPF 
and OSPF version 3 (OSPFv3). 


e RFC 1583, OSPF Version 2 
e RFC 1765, OSPF Database Overflow 
e RFC 1793, Extending OSPF to Support Demand Circuits 
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RFC 1850, OSPF Version 2 Management Information Base 
RFC 2154, OSPF with Digital Signatures 

RFC 2328, OSPF Version 2 

RFC 2370, The OSPF Opaque LSA Option 


Support is provided by the update-threshold configuration statement at the [edit protocols rsvp interface 
interface-name ] hierarchy level. 


RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option 

RFC 3623, Graceful OSPF Restart 

RFC 3630, Traffic Engineering (TE) Extensions to OSPF Version 2 

RFC 4136, OSPF Refresh and Flooding Reduction in Stable Topologies 

RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 
Only interface switching is supported. 

RFC 4552, Authentication/Confidentiality for OSPFv3 


RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual 
Private Networks (VPNs) 


RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) 
RFC 4811, OSPF Out-of-Band Link State Database (LSDB) Resynchronization 

RFC 4812, OSPF Restart Signaling 

RFC 4813, OSPF Link-Local Signaling 

RFC 4915, Multi-Topology (MT) Routing in OSPF 

RFC 5185, OSPF Multi-Area Adjacency 

RFC 5187, OSPFv3 Graceful Restart 

RFC 5250, The OSPF Opaque LSA Option 


NOTE: RFC 4750, mentioned in this RFC as a "should" requirement is not supported. However, 
RFC 1850, the predecessor to RFC 4750 is supported. 


RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates 

RFC 5340, OSPF for IPvé (RFC 2740 is obsoleted by RFC 5340) 

RFC 5838, Support of Address Families in OSPFv3 

Internet draft draft-ietf-ospf-af-alt-10.txt, Support of address families in OSPFv3 


Internet draft draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection 


Transmission of echo packets is not supported. 


The following RFCs do not define standards, but provide information about OSPF and related technologies. 
The IETF classifies them as “Informational.” 


e RFC 3137, OSPF Stub Router Advertisement 
e RFC 3509, Alternative Implementations of OSPF Area Border Routers 


e RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols 


SEE ALSO 


Supported IPv6é Standards 


Accessing Standards Documents on the Internet 
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Understanding OSPF Configurations 


To activate OSPF on a network, you must enable the protocol on all interfaces within the network on 
which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the device 
within an OSPF area. Once the interfaces are configured, OSPF link-state advertisements (LSAs) are 
transmitted on all OSPF-enabled interfaces, and the network topology is shared throughout the network. 


To complete the minimum device configuration for a node in an OSPF network involves: 


1. Configuring the device interfaces. 
See the Junos OS Network Interfaces Library for Routing Devices or the Junos OS Interfaces Configuration 
Guide for Security Devices. 


2. Configuring the router identifiers for the devices in your OSPF network 


3. Creating the backbone area (area O) for your OSPF network and adding the appropriate interfaces to 
the area 


NOTE: Once you complete this step, OSPF begins sending LSAs. No additional configuration 
is required to enable OSPF traffic on the network. 


You can further define your OSPF network depending on your network requirements. Some optional 
configurations involve: 


e Adding additional areas to your network and configure area border routers (ABRs) 


Enabling dial-on-demand routing backup on the OSPF-enabled interface to configure OSPF across a 
demand circuit such as an ISDN link. (You must have already configured an ISDN interface.) Because 


demand circuits do not pass all traffic required to maintain an OSPF adjacency (hello packets, for example), 
you configure dial-on-demand routing so individual nodes in an OSPF network can maintain adjacencies 
despite the lack of LSA exchanges. 


Reducing the amount of memory that the nodes use to maintain the topology database by configuring 


stub and not-so-stubby areas 


Ensuring that only trusted routing devices participate in the autonomous systems’ routing by enabling 


authentication 


Controlling the flow of traffic across the network by configuring path metrics and route selection 


When describing how to configure OSPF, the following terms are used as follows: 


e OSPF refers to both OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3) 
e OSPFv2 refers to OSPF version 2 
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e OSPFv3 refers to OSPF version 3 
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Configuring OSPF Interfaces 


IN THIS SECTION 


About OSPF Interfaces | 38 

Example: Configuring an Interface on a Broadcast or Point-to-Point Network | 40 
Example: Configuring OSPF Demand Circuits | 43 

Example: Configuring a Passive OSPF Interface | 46 

Example: Configuring OSPFv2 Peer interfaces | 49 

Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint Network | 55 
Understanding Multiple Address Families for OSPFv3 | 57 


Example: Configuring Multiple Address Families for OSPFv3 | 58 


| About OSPF Interfaces 


To activate OSPF on a network, you must enable the OSPF protocol on one or more interfaces on each 
device within the network on which traffic is to travel. How you configure the interface depends on 
whether the interface is connected to a broadcast or point-to-point network, a point-to-multipoint network, 
a nonbroadcast multiaccess (NBMA) network, or across a demand circuit. 


e A broadcast interface behaves as if the routing device is connected to a LAN. 


e A point-to-point interface provides a connection between a single source and a single destination (there 
is only one OSPF adjacency). 


e A point-to-multipoint interface provides a connection between a single source and multiple destinations. 


e AnNBMA interface behaves in a similar fashion to a point-to-multipoint interface, but you might configure 
an NBMA interface to interoperate with other equipment. 


e Ademand circuit is a connection on which you can limit traffic based on user agreements. The demand 
circuit can limit bandwidth or access time based on agreements between the provider and user. 


You can also configure an OSPF interface to be passive, to operate in passive traffic engineering mode, 
or to be a peer interface. 


e A passive interface advertises its address, but does not run the OSPF protocol (adjacencies are not 
formed and hello packets are not generated). 


e An interface operating in OSPF passive traffic engineering mode floods link address information within 
the autonomous system (AS) and makes it available for traffic engineering calculations. 


e Apeer interface can be configured for OSPF v2 routing devices. A peer interface is required for Generalized 
MPLS (GMPLS) to transport traffic engineering information through a link separate from the control 
channel. You establish this separate link by configuring a peer interface. The peer interface name must 
match the Link Management Protocol (LMP) peer name. A peer interface is optional for a hierarchy of 
RSVP label-switched paths (LSPs). After you configure the forwarding adjacency, you can configure 
OSPF v2 to advertise the traffic engineering properties of a forwarding adjacency to a specific peer. 


Point-to-point interfaces differ from multipoint in that only one OSPF adjacency is possible. (A LAN, for 

instance, can have multiple addresses and can run OSPF on each subnet simultaneously.) As such, when 

you configure a numbered point-to-point interface to OSPF by name, multiple OSPF interfaces are created. 
One, which is unnumbered, is the interface on which the protocol is run. An additional OSPF interface is 
created for each address configured on the interface, if any, which is automatically marked as passive. 


For OSPFv3, one OSPF-specific interface must be created per interface name configured under OSPFv3. 
OSPFv3 does not allow interfaces to be configured by IP address. 


Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable 
statement), and not actually having OSPF run on an interface (by including the passive statement) are 
mutually exclusive states. 


NOTE: When you configure OSPFv2 on an interface, you must also include the family inet 
statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. When 
you configure OSPFv3 on an interface, you must also include the family inet6 statement at the 
[edit interfaces interface-name unit logical-unit-number] hierarchy level. In Junos OS Release 9.2 
and later, you can configure OSPFv3 to support address families other than unicast IPvé. 


SEE ALSO 


Example: Configuring OSPF Passive Traffic Engineering Mode | 403 
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Example: Configuring an Interface on a Broadcast or Point-to-Point Network 


IN THIS SECTION 


Requirements | 40 
Overview | 40 


Configuration | 41 


Verification | 43 


This example shows how to configure an OSPF interface on a broadcast or point-to-point network. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


If the interface on which you are configuring OSPF supports broadcast mode (such as a LAN), or if the 
interface supports point-to-point mode (such as a PPP interface or a point-to-point logical interface on 
Frame Relay), you specify the interface by including the IP address or the interface name for OSPF v2, or 
only the interface name for OSPFv3. In Junos OS Release 9.3 and later, an OSPF point-to-point interface 
can be an Ethernet interface without a subnet. If you configure an interface on a broadcast network, 
designated router and backup designated router election is performed. 


NOTE: Using both the interface name and the IP address of the same interface produces an 
invalid configuration. 


In this example, you configure interface ge-0/2/0 as an OSPFv2 interface in OSPF area 0.0.0.1. 
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Configuration 


CLI Quick Configuration 

To quickly configure an OSPF interface on a broadcast or point-to-point network and to allow the inbound 
OSPF into the interfaces that are active, copy the following commands, paste them into a text file, remove 
any line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 

set interfaces ge-0/2/0 unit O family inet address 10.0.0.1 

set protocols ospf area 0.0.0.1 interface ge-0/2/0 

set security zones security-zone Trust host-inbound-traffic protocols all 

set security zones security-zone Trust host-inbound-traffic system-services all 
set groups global security policies default-policy permit-all 

set security zones security-zone Trust interfaces ge-0/2/0 


Step-by-Step Procedure 


To configure an OSPF interface on a broadcast or point-to-point network: 


1. Configure the interface. 


NOTE: For an OSPFv3 interface, specify an IPvé6 address. 


[edit] 
user@host# set interfaces ge-0/2/0 unit O family inet address 10.0.0.1 


2. Create an OSPF area. 


NOTE: For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy 


level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


3. Assign the interface to the area. 
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[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface ge-0/2/0 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1 ] 


5. To allow the inbound OSPF into the interfaces that are active. 


[edit] 

user@host# set security zones security-zone Trust host-inbound-traffic protocols all 
user@host# set security zones security-zone Trust host-inbound-traffic system-services all 
user@host# set groups global security policies default-policy permit-all 

user@host# set security zones security-zone Trust interfaces ge-0/2/0 

user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 


the configuration. 


user@host# show interfaces 
ge-0/2/0 { 
unit O { 
family inet { 
address 10.0.0.1/32; 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface ge-0/2/0.0; 


To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands. 
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Verification 


Confirm that the configuration is working properly. 


Verifying the OSPF Interface 


Purpose 


Verify the interface configuration. Depending on your deployment, the Type field might display LAN or 
P2P. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Example: Configuring OSPF Demand Circuits 
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Overview | 44 


Configuration | 44 


Verification | 46 


This example shows how to configure an OSPF demand circuit interface. 


Requirements 
Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


NOTE: If you are using OSPF demand circuits over an ISDN link, you must configure an ISDN 
interface and enable dial-on-demand routing. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


44 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


OSPF sends periodic hello packets to establish and maintain neighbor adjacencies and uses link-state 
advertisements (LSAs) to make routing calculations and decisions. OSPF support for demand circuits is 
defined in RFC 1793, Extending OSPF to Support Demand Circuits, and suppresses the periodic hello packets 
and LSAs. A demand circuit is a connection on which you can limit traffic based on user agreements. The 
demand circuit can limit bandwidth or access time based on agreements between the provider and user. 


You configure demand circuits on an OSPF interface. When the interface becomes a demand circuit, all 
hello packets and LSAs are suppressed as soon as OSPF synchronization is achieved. LSAs have a DoNotAge 
bit that stops the LSA from aging and prevents periodic updates from being sent. Hello packets and LSAs 
are sent and received on a demand-circuit interface only when there is a change in the network topology. 
This reduces the amount of traffic through the OSPF interface. 


Consider the following when configuring OSPF demand circuits: 


e Periodic hellos are only suppressed on point-to-point and point-to-multipoint interfaces. If you configure 
demand circuits on an OSPF broadcast network or on an OSPF nonbroadcast multiaccess (NBMA) 
network, periodic hello packets are still sent. 


e Demand circuit support on an OSPF point-to-multipoint interface resembles that for point-to-point 
interfaces. If you configure a point-to-multipoint interface as a demand circuit, the device negotiates 
hello suppression separately on each interface that is part of the point-to-multipoint network. 


This example assumes that you have a point-to-point connection between two devices using SONET/SDH 
interfaces. A demand-circuit interface automatically negotiates the demand-circuit connection with its 
OSPF neighbor. If the neighbor does not support demand circuits, then no demand circuit connection is 
established. 


In this example, you configure OSPF interface so-0/1/0 in OSPF area 0.0.0.1 as a demand circuit. 


Configuration 


CLI Quick Configuration 

To quickly configure an OSPF demand circuit interface, copy the following commands, paste them into a 
text file, remove any line breaks, change any details necessary to match your network configuration, copy 
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 


[edit] 
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set protocols ospf area 0.0.0.1 interface so-0/1/0 demand-circuit 


Step-by-Step Procedure 


To configure an OSPF demand circuit interface on one neighboring interface: 


1. Create an OSPF area. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit ] 
user@host# edit protocols ospf area 0.0.0.1 


2. Configure the neighboring interface as a demand circuit. 


[edit protocols ospf area 0.0.0.1] 
user@host# set interface so-0/1/0 demand-circuit 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1] 
user@host# commit 


NOTE: Repeat this entire configuration on the other neighboring interface. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols 
ospf { 
area 0.0.0.1 { 
interface so-0/1/0.0 { 
demand-circuit; 


} 
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To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Status of Neighboring Interfaces 


Purpose 
Verify information about the neighboring interface. When the neighbor is configured for demand circuits, 
a DC flag displays. 


Action 
From operational mode, enter the show ospf neighbor detail command for OSPFv2, and enter the show 
ospf3 neighbor detail command for OSPFv3. 


Example: Configuring a Passive OSPF Interface 
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This example shows how to configure a passive OSPF interface. A passive OSPF interface advertises its 
address but does not run the OSPF protocol. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 
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e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


By default, OSPF must be configured on an interface for direct interface addresses to be advertised as 
interior routes. To advertise the direct interface addresses without actually running OSPF on that interface 
(adjacencies are not formed and hello packets are not generated), you configure that interface as a passive 
interface. 


Enabling OSPF on an interface (by including the interface statement), disabling it (by including the disable 
statement), and not actually having OSPF run on an interface (by including the passive statement) are 
mutually exclusive states. 


NOTE: If you do not want to see notifications for state changes in a passive OSPF interface, 
you can disable the OSPF traps for the interface by including the no-interface-state-traps 
statement. The no-interface-state-traps statement is supported only for OSPFv2. 


In this example, you configure interface ge-0/2/0 as a passive OSPF interface in area 0.0.0.1 by including 
the passive statement. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
set protocols ospf area 0.0.0.1 interface ge-0/2/0 passive 


Step-by-Step Procedure 


To configure a passive OSPF interface: 


1. Create an OSPF area. 


NOTE: For an OSPFv3 interface, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


2. Configure the passive interface. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface ge-0/2/0 passive 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface ge-0/2/0.0 { 
passive; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Status of OSPF Interfaces 
Purpose 


Verify the status of the OSPF interface. If the interface is passive, the Adj count field is O because no 
adjacencies have been formed. Next to this field, you might also see the word Passive. 
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Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Example: Configuring OSPFv2 Peer interfaces 
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This example shows how to configure an OSPFv2 peer interface. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


e Configure Generalized MPLS per your network requirements. . 


Overview 


You can configure an OSPF v2 peer interface for many reasons, including when you configure Generalized 
MPLS (GMPLS). This example configures a peer interface for GMPLS. GMPLS requires traffic engineering 
information to be transported through a link separate from the control channel. You establish this separate 
link by configuring a peer interface. The OSPFv2 peer interface name must match the Link Management 
Protocol (LMP) peer name. You configure GMPLS and the LMP settings separately from OSPF. 
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This example assumes that GMPLS and the LMP peer named oxc1 are already configured, and you need 
to configure the OSPFv2 peer interface in area 0.0.0.0. 


Configuration 


CLI Quick Configuration 


To quickly configure an OSPFv2 peer interface, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configuration, copy and paste 
the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
set protocols ospf area 0.0.0.0 peer-interface oxc1 


Step-by-Step Procedure 
To configure a peer OSPFv2 interface used by the LMP: 


1. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Configure the peer interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# set peer-interface oxc1 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
peer-interface oxc1; 
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Verification 


Confirm that the configuration is working properly. 


Verifying the Configured OSPFv2 Peer 


Purpose 


Verify the status of the OSPFv2 peer. When an OSPF v2 peer is configured for GMPLS, the Peer Name 
field displays the name of the LMP peer that you created for GMPLS, which is also the configured OSPFv2 
peer. 


Action 


From operational mode, enter the show link-management command. 


Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess 
Network 
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This example shows how to configure an OSPF v2 interface on a nonbroadcast multiaccess (NBMA) network. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


When you configure OSPFv2 on an NBMA network, you can use nonbroadcast mode rather than 
point-to-multipoint mode. Using this mode offers no advantages over point-to-multipoint mode, but it has 
more disadvantages than point-to-multipoint mode. Nevertheless, you might occasionally find it necessary 
to configure nonbroadcast mode to interoperate with other equipment. Because there is no autodiscovery 
mechanism, you must configure each neighbor. 


Nonbroadcast mode treats the NBMA network as a partially connected LAN, electing designated and 
backup designated routers. All routing devices must have a direct connection to both the designated and 
backup designated routers, or unpredictable results occur. 


When you configure the interface, specify either the IP address or the interface name. Using both the IP 
address and the interface name produces an invalid configuration. For nonbroadcast interfaces, specify 
the IP address of the nonbroadcast interface as the interface name. 


In this example, you configure the Asynchronous Transfer Mode (ATM) interface at-0/1/0 as an OSPFv2 
interface in OSPF area 0.0.0.1, and you and specify the following settings: 


interface-type nbma-—Sets the interface to run in NBMA mode. You must explicitly configure the interface 
to run in NBMA mode. 


neighbor address <eligible>—Specifies the IP address of the neighboring device. OSPF routing devices 


normally discover their neighbors dynamically by listening to the broadcast or multicast hello packets 
on the network. Because an NBMA network does not support broadcast (or multicast), the device cannot 
discover its neighbors dynamically, so you must configure all the neighbors statically. To configure 
multiple neighbors, include multiple neighbor statements. If you want the neighbor to be a designated 
router, include the eligible keyword. 


poll-interval—Specifies the length of time, in seconds, before the routing device sends hello packets out 


of the interface before it establishes adjacency with a neighbor. Routing devices send hello packets for 
a longer interval on nonbroadcast networks to minimize the bandwidth required on slow WAN links. 
The range is from 1 through 255 seconds. By default, the device sends hello packets out the interface 
every 120 seconds before it establishes adjacency with a neighbor. 


Once the routing device detects an active neighbor, the hello packet interval changes from the time 
specified in the poll-interval statement to the time specified in the hello-interval statement. 


Configuration 


CLI Quick Configuration 

To quickly configure an OSPF v2 interface on an NBMA network, copy the following commands, paste 
them into a text file, remove any line breaks, change any details necessary to match your network 
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter 
commit from configuration mode. 
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[edit] 

set interfaces at-0/1/0 unit O family inet address 192.0.2.1 

set protocols ospf area 0.0.0.1 interface at-0/1/0.0 interface-type nbma 

set protocols ospf area 0.0.0.1 interface at-0/1/0.0 neighbor 192.0.2.2 eligible 
set protocols ospf area 0.0.0.1 interface at-0/1/0.0 poll-interval 130 


Step-by-Step Procedure 


To configure an OSPF v2 interface on an NBMA network: 


1. Configure the interface. 


[edit] 
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.1 


2. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


3. Assign the interface to the area. 
In this example, include the eligible keyword to allow the neighbor to be a designated router. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface at-0/1/0 interface-type nbma neighbor 192.0.2.2 eligible 


4. Configure the poll interval. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface at-0/1/0 poll-interval 130 


5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
at-0/1/0 { 
unit O { 
family inet { 
address 192.0.2.1/32; 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface at-0/1/0.0 { 
interface-type nbma; 
neighbor 192.0.2.2 eligible; 
poll-interval 130; 


Verification 


Confirm that the configuration is working properly. 


Verifying the OSPF Interface 


Purpose 


Verify the interface configuration. Confirm that the Type field displays NBMA. 


Action 


From operational mode, enter the show ospf interface detail command. 


SEE ALSO 


OSPF Timers Overview | 282 
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Example: Configuring an OSPFv2 Interface on a Point-to-Multipoint 


Network 


IN THIS SECTION 


Requirements | 55 
Overview | 55 
Configuration | 55 
Verification | 57 


This example shows how to configure an OSPFv2 interface on a point-to-multipoint network. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election’ 


) 


on page 71 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


When you configure OSPFv2 on a nonbroadcast multiaccess (NBMA) network, such as a multipoint 
Asynchronous Transfer Mode (ATM) or Frame Relay, OSPFv2 operates by default in point-to-multipoint 
mode. In this mode, OSPFv2 treats the network as a set of point-to-point links. Because there is no 


autodiscovery mechanism, you must configure each neighbor. 


When you configure the interface, specify either the IP address or the interface name. Using both the IP 


address and the interface name produces an invalid configuration. 


In this example, you configure ATM interface at-0/1/0 as an OSPF v2 interface in OSPF area 0.0.0.1, and 
you and specify 192.0.2.1 as the neighbor’s IP address. 


Configuration 


CLI Quick Configuration 


56 


To quickly configure an OSPF v2 interface on a point-to-multipoint network, copy the following commands 
and paste them into the CLI. 


[edit] 
set interfaces at-0/1/0 unit O family inet address 192.0.2.2 
set protocols ospf area 0.0.0.1 interface at-0/1/0 neighbor 192.0.2.1 


Step-by-Step Procedure 


To configure an OSPF v2 interface on a point-to-multipoint network: 


1. Configure the interface. 


[edit] 
user@host# set interfaces at-0/1/0 unit 0 family inet address 192.0.2.2 


2. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


3. Assign the interface to the area and specify the neighbor. 


[edit protocols ospf area 0.0.0.1] 
user@host# set interface at-0/1/0 neighbor 192.0.2.1 


To configure multiple neighbors, include a neighbor statement for each neighbor. 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
at-0/1/0 { 


unit O { 
family inet { 
address 192.0.2.2/32; 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface at-0/1/0.0 { 
neighbor 192.0.2.1; 
} 


Verification 


Confirm that the configuration is working properly. 


Verifying the OSPF Interface 


Purpose 


Verify the interface configuration. Confirm that the Type field displays P2MP. 


Action 


From operational mode, enter the show ospf interface detail command. 


Understanding Multiple Address Families for OSPFv3 


By default, OSPFv3 supports only unicast IPvé6 routes. In Junos OS Release 9.2 and later, you can configure 
OSPFv3 to support multiple address families, including IPv4 unicast, IPv4 multicast, and IPv6é multicast. 
This mutliple address family support allows OSPFv3 to support both IPv6 and IPv4 nodes. Junos OS maps 
each address family to a separate realm as defined in Internet draft draft-ietf-ospf-af-alt-06.txt, Support 
for Address Families in OSPFv3. Each realm maintains a separate set of neighbors and link-state database. 


When you configure multiple address families for OSPFv3, there is a new instance ID field that allows 
multiple OSPFv3 protocol instances per link. This allows a single link to belong to multiple areas. 


You configure each realm independently. We recommend that you configure an area and at least one 
interface for each realm. 
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These are the default import and export routing tables for each of the four address families: 


e IPv6 unicast: inet6.0 
e IPv6é multicast: inet6.2 
e |Pv4 unicast: inet.0 


e IPv4 multicast: inet.2 


With the exception of virtual links, all configurations supported for the default IPv6 unicast family are 
supported for the address families that have to be configured as realms. 


Example: Configuring Multiple Address Families for OSPFv3 
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This example shows how to configure multiple address families for OSPFv3. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 
Overview 


By default, OSPFv3 supports unicast IPv6 routes, but you can configure OSPFv3 to support multiple 
address families. To support an address family other than unicast IPv6, you configure a realm that allows 
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OSPFv3 to advertise IPv4 unicast, IPv4 multicast, or IPv6 multicast routes. Junos OS then maps each 
address family that you configure to a separate realm with its own set of neighbors and link-state database. 


NOTE: By default, LDP synchronization is only supported for OSPF v2. If you configure an IPv4 
unicast or IPv4 multicast realm, you can also configure LDP synchronization. Since LDP 
synchronization is only supported for IPv4, this support is only available for OSPF v3 if you 
configure an IPv4 realm. 


When configuring OSPFv3 to support multiple address families, consider the following: 


e You configure each realm independently. We recommend that you configure an area and at least one 
interface for each realm. 


e OSPF v3 uses IPv6 link-local addresses as the source of hello packets and next hop calculations. As such, 
you must enable IPvé on the link regardless of the additional realm you configure. 


Figure 2 on page 59 shows a connection between Routers RO and R1. In this example, you configure 
interface fe-0/1/0 on Router RO in area O to advertise IPv4 unicast routes, in addition to the default unicast 
IPvé6 routes in area 1, by including the realm ipv4-unicast statement. Depending on your network 
requirements, you can also advertise IPv4 multicast routes by including the realm-ipv4-multicast statement, 
and you can advertise IPv6 multicast routes by including the realm-ipv6-multicast statement. 


Figure 2: IPv4 Unicast Realm 


Area 1 
IPv4 Unicast Realm 
fe-0/1/0 
Area 0 
Area 2 
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Configuration 


CLI Quick Configuration 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide. 
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To quickly configure multiple address families for OSPF v3, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 192.0.2.2/24 

set interfaces fe-0/1/0 unit O family ineté 

set protocols ospf3 area 0.0.0.0 interface fe-0/1/0 

set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0 


Step-by-Step Procedure 


To configure multiple address families for OSPFv3: 


1. Configure the device interface participating in OSPFv3. 
[edit] 


user@host# set interfaces fe-0/1/0 unit O family inet address 192.0.2.2/24 
user@host# set interfaces fe-0/1/0 unit O family inet6 


2. Enter OSPFv3 configuration mode. 


[edit ] 
user@host# edit protocols ospf3 


3. Add the interface you configured to the OSPFv3 area. 


[edit protocols ospf3 ] 
user@host# set area 0.0.0.0 interface fe-0/1/0 


4. Configure an IPv4 unicast realm. This allows OSPFv3 to support both IPv4 unicast and IPv6 unicast 
routes. 


[edit protocols ospf3 ] 
user@host# set realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0 


5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf3 ] 


user@host# commit 


NOTE: Repeat this entire configuration on the neighboring device that is part of the realm. 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
fe-0/1/0 { 
unit O { 
family inet { 
address 192.0.2.2/24, 
} 
family inet6; 


user@host# show protocols ospf3 
realm ipv4-unicast { 
area 0.0.0.0 { 
interface fe-0/1/0.0; 


area 0.0.0.0 { 
interface fe-0/1/0.0; 


Verification 
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@ Verifying the Link-State Database | 62 
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Confirm that the configuration is working properly. 


Verifying the Link-State Database 


Purpose 


Verify the status of the link-state database for the configured realm, or address family. 


Action 


From operational mode, enter the show ospf3 database realm ipv4-unicast command. 


Verifying the Status of OSPFv3 Interfaces with Multiple Address Families 


Purpose 
Verify the status of the interface for the specified OSPFv3 realm, or address family. 


Action 


From operational mode, enter the show ospf3 interface realm ipv4-unicast command. 
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OSPF Area Types and Accepted LSAs | 68 


In OSPF, a single autonomous system (AS) can be divided into smaller groups called areas. This reduces 
the number of link-state advertisements (LSAs) and other OSPF overhead traffic sent on the network, and 
it reduces the size of the topology database that each router must maintain. The routing devices that 
participate in OSPF routing perform one or more functions based on their location in the network. 


This topic describes the following OSPF area types and routing device functions: 


Areas 


An area is aset of networks and hosts within an AS that have been administratively grouped together. We 
recommend that you configure an area as a collection of contiguous IP subnetted networks. Routing 
devices that are wholly within an area are called internal routers. All interfaces on internal routers are 
directly connected to networks within the area. 


The topology of an area is hidden from the rest of the AS, thus significantly reducing routing traffic in the 
AS. Also, routing within the area is determined only by the area’s topology, providing the area with some 
protection from bad routing data. 


All routing devices within an area have identical topology databases. 
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Area Border Routers 


Routing devices that belong to more than one area and connect one or more OSPF areas to the backbone 
area are called area border routers (ABRs). At least one interface is within the backbone while another 
interface is in another area. ABRs also maintain a separate topological database for each area to which 
they are connected. 


Backbone Areas 


An OSPF backbone area consists of all networks in area ID 0.0.0.0, their attached routing devices, and all 
ABRs. The backbone itself does not have any ABRs. The backbone distributes routing information between 
areas. The backbone is simply another area, so the terminology and rules of areas apply: a routing device 
that is directly connected to the backbone is an internal router on the backbone, and the backbone’s 
topology is hidden from the other areas in the AS. 


The routing devices that make up the backbone must be physically contiguous. If they are not, you must 
configure virtual links to create the appearance of backbone connectivity. You can create virtual links 
between any two ABRs that have an interface to a common nonbackbone area. OSPF treats two routing 
devices joined by a virtual link as if they were connected to an unnumbered point-to-point network. 


AS Boundary Routers 


Routing devices that exchange routing information with routing devices in non-OSPF networks are called 
AS boundary routers. They advertise externally learned routes throughout the OSPF AS. Depending on the 
location of the AS boundary router in the network, it can be an ABR, a backbone router, or an internal 
router (with the exception of stub areas). Internal routers within a stub area cannot be an AS boundary 
router because stub areas cannot contain any Type 5 LSAs. 


Routing devices within the area where the AS boundary router resides know the path to that AS boundary 
router. Any routing device outside the area only knows the path to the nearest ABR that is in the same 
area where the AS boundary router resides. 


Backbone Router 


Backbone routers are routing devices that have one or more interfaces connected to the OSPF backbone 
area (area ID 0.0.0.0). 


Internal Router 


Routing devices that connect to only one OSPF area are called internal routers. All interfaces on internal 
routers are directly connected to networks within a single area. 


Stub Areas 


Stub areas are areas through which or into which AS external advertisements are not flooded. You might 
want to create stub areas when much of the topological database consists of AS external advertisements. 
Doing so reduces the size of the topological databases and therefore the amount of memory required on 
the internal routers in the stub area. 


Routing devices within a stub area rely on the default routes originated by the area’s ABR to reach external 
AS destinations. You must configure the default-metric option on the ABR before it advertises a default 
route. Once configured, the ABR advertises a default route in place of the external routes that are not 
being advertised within the stub area, so that routing devices in the stub area can reach destinations 
outside the area. 


The following restrictions apply to stub areas: you cannot create a virtual link through a stub area, a stub 
area cannot contain an AS boundary router, the backbone cannot be a stub area, and you cannot configure 
an area as both a stub area and a not-so-stubby area. 


Not-So-Stubby Areas 


An OSPF stub area has no external routes in it, so you cannot redistribute from another protocol into a 
stub area. A not-so-stubby area (NSSA) allows external routes to be flooded within the area. These routes 
are then leaked into other areas. However, external routes from other areas still do not enter the NSSA. 


The following restriction applies to NSSAs: you cannot configure an area as both a stub area and an NSSA. 


Transit Areas 


Transit areas are used to pass traffic from one adjacent area to the backbone (or to another area if the 
backbone is more than two hops away from an area). The traffic does not originate in, nor is it destined 
for, the transit area. 
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OSPF Area Types and Accepted LSAs 


The following table gives details about OSPF area types and accepted LSAs: 


OSPF Area Types and Accepted LSAs 


Area Types LSA1 LSA2 LSA3 LSA4 _ LSA5- LSA7 


Backbone Area 


Non-Backbone Area 


Stub Area 


Totally Stubby Area 


Not-So-Stubby Area 
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| OSPF Designated Router Overview 


Large LANs that have many routing devices and therefore many OSPF adjacencies can produce heavy 
control-packet traffic as link-state advertisements (LSAs) are flooded across the network. To alleviate the 
potential traffic problem, OSPF uses designated routers on all multiaccess networks (broadcast and 
nonbroadcast multiaccess [NBMA] networks types). Rather than broadcasting LSAs to all their OSPF 
neighbors, the routing devices send their LSAs to the designated router. Each multiaccess network has a 
designated router, which performs two main functions: 


e Originate network link advertisements on behalf of the network. 


e Establish adjacencies with all routing devices on the network, thus participating in the synchronizing of 
the link-state databases. 


In LANs, the election of the designated router takes place when the OSPF network is initially established. 
When the first OSPF links are active, the routing device with the highest router identifier (defined by the 
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router-id configuration value, which is typically the IP address of the routing device, or the loopback 
address) is elected the designated router. The routing device with the second highest router identifier is 
elected the backup designated router. If the designated router fails or loses connectivity, the backup 
designated router assumes its role and a new backup designated router election takes place between all 
the routers in the OSPF network. 


OSPF uses the router identifier for two main purposes: to elect a designated router, unless you manually 
specify a priority value, and to identify the routing device from which a packet is originated. At designated 
router election, the router priorities are evaluated first, and the routing device with the highest priority is 
elected designated router. If router priorities tie, the routing device with the highest router identifier, 
which is typically the routing device's IP address, is chosen as the designated router. If you do not configure 
a router identifier, the IP address of the first interface to come online is used. This is usually the loopback 
interface. Otherwise, the first hardware interface with an IP address is used. 


At least one routing device on each logical IP network or subnet must be eligible to be the designated 
router for OSPF v2. At least one routing device on each logical link must be eligible to be the designated 
router for OSPFvs3. 


By default, routing devices have a priority of 128. A priority of O marks the routing device as ineligible to 
become the designated router. A priority of 1 means the routing device has the least chance of becoming 
a designated router. A priority of 255 means the routing device is always the designated router. 


| Example: Configuring an OSPF Router Identifier 


IN THIS SECTION 


Requirements | 69 
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This example shows how to configure an OSPF router identifier. 


Requirements 


Before you begin: 
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e Identify the interfaces on the routing device that will participate in OSPF. You must enable OSPF on all 
interfaces within the network on which OSPF traffic is to travel. 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices 


Overview 


The router identifier is used by OSPF to identify the routing device from which a packet originated. Junos 
OS selects a router identifier according to the following set of rules: 


1. By default, Junos OS selects the lowest configured physical IP address of an interface as the router 
identifier. 


2. If a loopback interface is configured, the IP address of the loopback interface becomes the router 
identifier. 


3. If multiple loopback interfaces are configured, the lowest loopback address becomes the router identifier. 


4. If a router identifier is explicitly configured using the router-id address statement under the [edit 
routing-options] hierarchy level, the above three rules are ignored. 


NOTE: 1. The router identifier behavior described here holds good even when configured under 
[edit routing-instances routing-instance-name routing-options] and [edit logical-systems 
logical-system-name routing-instances routing-instance-name routing-options] hierarchy levels. 


2. If the router identifier is modified in a network, the link-state advertisements (LSAs) advertised 
by the previous router identifier are retained in the OSPF database until the LSA retransmit 
interval has timed out. Hence, it is strongly recommended that you explicitly configure the router 
identifier under the [edit routing-options] hierarchy level to avoid unpredictable behavior if the 
interface address on a loopback interface changes. 


In this example, you configure the OSPF router identifier by setting its router ID value to the IP address 
of the device, which is 192.0.2.24. 


Configuration 


CLI Quick Configuration 


To quickly configure an OSPF router identifier, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configuration, copy and paste 
the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
set routing-options router-id 192.0.2.24 
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Step-by-Step Procedure 


To configure an OSPF router identifier: 


1. Configure the OSPF router identifier by entering the [router-id] configuration value. 


[edit] 
user@host# set routing-options router-id 192.0.2.24 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 
Confirm your configuration by entering the show routing-options router-id command. If the output does 


not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show routing-options router-id 
router-id 192.0.2.24- 


Verification 


After you configure the router ID and activate OSPF on the routing device, the router ID is referenced by 
multiple OSPF operational mode commands that you can use to monitor and troubleshoot the OSPF 
protocol. The router ID fields are clearly marked in the output. 


| Example: Controlling OSPF Designated Router Election 
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This example shows how to control OSPF designated router election. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Overview 


This example shows how to control OSPF designated router election. Within the example, you set the 
OSPF interface to ge-/0/0/1 and the device priority to 200. The higher the priority value, the greater 
likelihood the routing device will become the designated router. 


By default, routing devices have a priority of 128. A priority of O marks the routing device as ineligible to 
become the designated router. A priority of 1 means the routing device has the least chance of becoming 
a designated router. 


Configuration 


CLI Quick Configuration 


To quickly configure an OSPF designated router election, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. 


[edit] 
set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200 


Step-by-Step Procedure 


To control OSPF designated router election: 


1. Configure an OSPF interface and specify the device priority. 


NOTE: To specify an OSPF v3 interface, include the ospf3 statement at the [edit protocols] 
hierarchy level. 
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[edit] 
user@host# set protocols ospf area 0.0.0.3 interface ge-0/0/1 priority 200 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 
Confirm your configuration by entering the show protocols ospf command. If the output does not display 


the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.3 { 
interface ge-0/0/1.0 { 
priority 200; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 
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Confirm that the configuration is working properly. 


Verifying the Designated Router Election 
Purpose 
Based on the priority you configured for a specific OSPF interface, you can confirm the address of the 


area’s designated router. The DR ID, DR, or DR-ID field displays the address of the area’s designated router. 
The BDR ID, BDR, or BDR-ID field displays the address of the backup designated router. 


Action 


From operational mode, enter the show ospf interface and the show ospf neighbor commands for OSPFv2, 
and enter the show ospf3 interface and the show ospf3 neighbor commands for OSPFv3. 


Understanding OSPF Areas and Backbone Areas 


OSPF networks in an autonomous system (AS) are administratively grouped into areas. Each area within 

an AS operates like an independent network and has a unique 32-bit area ID, which functions similar to a 
network address. Within an area, the topology database contains only information about the area, link-state 
advertisements (LSAs) are flooded only to nodes within the area, and routes are computed only within the 
area. The topology of an area is hidden from the rest of the AS, thus significantly reducing routing traffic 
in the AS. Subnetworks are divided into other areas, which are connected to form the whole of the main 
network. Routing devices that are wholly within an area are called internal routers. All interfaces on internal 
routers are directly connected to networks within the area. 


The central area of an AS, called the backbone area, has a special function and is always assigned the area 
ID 0.0.0.0. (Within a simple, single-area network, this is also the ID of the area.) Area IDs are unique numeric 
identifiers, in dotted decimal notation, but they are not IP addresses. Area IDs need only be unique within 
an AS. All other networks or areas in the AS must be directly connected to the backbone area by a routing 
device that has interfaces in more than one area. These connecting routing devices are called area border 
routers (ABRs). Figure 3 on page 74 shows an OSPF topology of three areas connected by two ABRs. 


Figure 3: Multiarea OSPF Topology 
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Because all areas are adjacent to the backbone area, OSPF routers send all traffic not destined for their 

own area through the backbone area. The ABRs in the backbone area are then responsible for transmitting 
the traffic through the appropriate ABR to the destination area. The ABRs summarize the link-state records 
of each area and advertise destination address summaries to neighboring areas. The advertisements contain 
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the ID of the area in which each destination lies, so that packets are routed to the appropriate ABR. For 
example, in the OSPF areas shown in Figure 3 on page 74, packets sent from Router A to Router C are 
automatically routed through ABR B. 


Junos OS supports active backbone detection. Active backbone detection is implemented to verify that 
ABRs are connected to the backbone. If the connection to the backbone area is lost, then the routing 
device’s default metric is not advertised, effectively rerouting traffic through another ABR with a valid 
connection to the backbone. Active backbone detection enables transit through an ABR with no active 
backbone connection. An ABR advertises to other routing devices that it is an ABR even if the connection 
to the backbone is down, so that the neighbors can consider it for interarea routes. 


An OSPF restriction requires all areas to be directly connected to the backbone area so that packets can 
be properly routed. All packets are routed first to the backbone area by default. Packets that are destined 
for an area other than the backbone area are then routed to the appropriate ABR and on to the remote 
host within the destination area. 


In large networks with many areas, in which direct connectivity between all areas and the backbone area 
is physically difficult or impossible, you can configure virtual links to connect noncontiguous areas. Virtual 
links use a transit area that contains two or more ABRs to pass network traffic from one adjacent area to 
another. For example, Figure 4 on page 75 shows a virtual link between a noncontiguous area and the 
backbone area through an area connected to both. 


Figure 4: OSPF Topology with a Virtual Link 
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In the topology shown in Figure 4 on page 75, a virtual link is established between area 0.0.0.3 and the 
backbone area through area 0.0.0.2. All outbound traffic destined for other areas is routed through area 
0.0.0.2 to the backbone area and then to the appropriate ABR. All inbound traffic destined for area 0.0.0.3 
is routed to the backbone area and then through area 0.0.0.2. 
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| Example: Configuring a Single-Area OSPF Network 
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This example shows how to configure a single-area OSPF network. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Overview 


To activate OSPF on a network, you must enable the OSPF protocol on all interfaces within the network 
on which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the 
device within an OSPF area. Once the interfaces are configured, OSPF LSAs are transmitted on all 
OSPF-enabled interfaces, and the network topology is shared throughout the network. 


In an autonomous system (AS), the backbone area is always assigned area ID 0.0.0.0 (within a simple, 
single-area network, this is also the ID of the area). Area IDs are unique numeric identifiers, in dotted 
decimal notation. Area IDs need only be unique within an AS. All other networks or areas in the AS must 
be directly connected to the backbone area by area border routers that have interfaces in more than one 
area. You must also create a backbone area if your network consists of multiple areas. In this example, you 
create the backbone area and add interfaces, such as ge-0/0/0, as needed to the OSPF area. 


To use OSPF on the device, you must configure at least one OSPF area, such as the one shown in 
Figure 5 on page 77. 


Figure 5: Typical Single-Area OSPF Network Topology 
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Configuration 


CLI Quick Configuration 

To quickly configure a single-area OSPF network, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, copy and 
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 


[edit] 
set protocols ospf area 0.0.0.0 interface ge-0/0/0 


Step-by-Step Procedure 


To configure a single-area OSPF network: 


1. Configure the single-area OSPF network by specifying the area ID and associated interface. 


NOTE: For a single-area OSPFv3 network, include the ospf3 statement at the [edit protocols] 
hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.0 interface ge-0/0/0 


2. If you are done configuring the device, commit the configuration. 


[edit] 
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user@host# commit 


Results 
Confirm your configuration by entering the show protocols ospf command. If the output does not display 


the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface ge-0/0/0.0; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 
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Confirm that the configuration is working properly. 


Verifying the Interfaces in the Area 


Purpose 


Verify that the interface for OSPF or OSPF v3 has been configured for the appropriate area. Confirm that 
the Area field displays the value that you configured. 


Action 


From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3 
interface command for OSPFv3. 
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| Example: Configuring a Multiarea OSPF Network 
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This example shows how to configure a multiarea OSPF network. To reduce traffic and topology 
maintenance for the devices in an OSPF autonomous system (AS), you can group the OSPF-enabled routing 
devices into multiple areas. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Overview 


To activate OSPF on a network, you must enable the OSPF protocol on all interfaces within the network 
on which OSPF traffic is to travel. To enable OSPF, you must configure one or more interfaces on the 
device within an OSPF area. Once the interfaces are configured, OSPF LSAs are transmitted on all 
OSPF-enabled interfaces, and the network topology is shared throughout the network. 


Each OSPF area consists of routing devices configured with the same area number. In Figure 6 on page 80, 
Router B resides in the backbone area of the AS. The backbone area is always assigned area ID 0.0.0.0. 
(All area IDs must be unique within an AS.) All other networks or areas in the AS must be directly connected 
to the backbone area by a router that has interfaces in more than one area. In this example, these area 


border routers are A, C, D, and E. You create an additional area (area 2) and assign it unique area ID 0.0.0.2, 
and then add interface ge-0/0/0 to the OSPF area. 


To reduce traffic and topology maintenance for the devices in an OSPF AS, you can group them into 
multiple areas as shown in Figure 6 on page 80. In this example, you create the backbone area, create an 
additional area (area 2) and assign it unique area ID 0.0.0.2, and you configure Device B as the area border 
router, where interface ge-0/0/0 participates in OSPF area O and interface ge-0/0/2 participates in OSPF 
area 2. 


Figure 6: Typical Multiarea OSPF Network Topology 











Configuration 


CLI Quick Configuration 


To quickly configure a multiarea OSPF network, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configuration, copy and paste 
the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


Device A 


[edit] 
set protocols ospf area 0.0.0.0 interface ge-0/0/0 
set protocols ospf area 0.0.0.0 interface ge-0/0/1 


Device C 


[edit] 
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set protocols ospf area 0.0.0.0 interface ge-0/0/0 


Device B 


[edit] 
set protocols ospf area 0.0.0.0 interface ge-0/0/0 
set protocols ospf area 0.0.0.2 interface ge-0/0/2 


Device D 


[edit] 
set protocols ospf area 0.0.0.2 interface ge-0/0/0 
set protocols ospf area 0.0.0.2 interface ge-0/0/2 


Device E 


[edit] 
set protocols ospf area 0.0.0.2 interface ge-0/0/2 


Step-by-Step Procedure 


To configure a multiarea OSPF network: 


1. Configure the backbone area. 


NOTE: For an OSPFv3 network, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@A# set protocols ospf area 0.0.0.0 interface ge-0/0/0 
user@A# set protocols ospf area 0.0.0.0 interface ge-0/0/1 


82 


[edit] 
user@C# set protocols ospf area 0.0.0.0 interface ge-0/0/0 


[edit] 
user@B# set protocols ospf area 0.0.0.0 interface ge-0/0/0 


2. Configure an additional area for your OSPF network. 


NOTE: For a multiarea OSPFv3 network, include the ospf3 statement at the [edit protocols] 
hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.2 interface ge-0/0/0 
user@D# set protocols ospf area 0.0.0.2 interface ge-0/0/2 


[edit] 
user@E# set protocols ospf area 0.0.0.2 interface ge-0/0/2 


3. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 

interface ge-0/0/0.0; 

interface ge-0/0/1.0; 


user@C# show protocols ospf 
area 0.0.0.0 { 


interface ge-0/0/0.0; 


user@B# show protocols ospf 
area 0.0.0.0 { 
interface ge-0/0/0.0; 


} 
area 0.0.0.2 { 
interface ge-0/0/2.0; 


user@D# show protocols ospf 
area 0.0.0.2 { 
interface ge-0/0/0.0; 
interface ge-0/0/2.0; 


user@E# show protocols ospf 
area 0.0.0.2 { 
interface ge-0/0/2.0; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 


@ Verifying the Interfaces in the Area | 83 


Confirm that the configuration is working properly. 


Verifying the Interfaces in the Area 


Purpose 


Verify that the interface for OSPF or OSPF v3 has been configured for the appropriate area. Confirm that 
the Area field displays the value that you configured. 


Action 
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From operational mode, enter the show ospf interface command for OSPFv2, and enter the show ospf3 
interface command for OSPFv3. 


| Understanding Multiarea Adjacency for OSPF 


By default, a single interface can belong to only one OSPF area. However, in some situations, you might 
want to configure an interface to belong to more than one area. Doing so allows the corresponding link 
to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area 
paths. For example, you can configure an interface to belong to multiple areas with a high-speed backbone 
link between two area border routers (ABRs) so you can create multiarea adjacencies that belong to 
different areas. 


In Junos OS Release 9.2 and later, you can configure a logical interface to belong to more than one OSPFv2 
area. Support for OSPFv3 was introduced in Junos OS Release 9.4. As defined in RFC 5185, OSPF Multi-Area 
Adjacency, the ABRs establish multiple adjacencies belonging to different areas over the same logical 
interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured 
area by the routers connected to the link. For each area, one of the logical interfaces is treated as primary, 
and the remaining interfaces that are configured for the area are designated as secondary. 


Any logical interface not configured as a secondary interface for an area is treated as the primary interface 
for that area. A logical interface can be configured as primary interface only for one area. For any other 
area for which you configure the interface, you must configure it as a secondary interface. 


| Example: Configuring Multiarea Adjacency for OSPF 
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This example shows how to configure multiarea adjacency for OSPF. 
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Requirements 


Before you begin, plan your multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” 
on page 79. 


Overview 


By default, a single interface can belong to only one OSPF area. You can configure a single interface to 
belong in multiple OSPF areas. Doing so allows the corresponding link to be considered an intra-area link 
in multiple areas and to be preferred over other higher-cost intra-area paths. When configuring a secondary 
interface, consider the following: 


For OSPFv2, you cannot configure point-to-multipoint and nonbroadcast multiaccess (NBMA) network 
interfaces as a secondary interface because secondary interfaces are treated as a point-to-point 


unnumbered link. 


Secondary interfaces are supported for LAN interfaces (the primary interface can be a LAN interface, 


but any secondary interfaces are treated as point-to-point unnumbered links over the LAN). In this 
scenario, you must ensure that there are only two routing devices on the LAN or that there are only two 
routing devices on the LAN that have secondary interfaces configured for a specific OSPF area. 


Since the purpose of a secondary interface is to advertise a topological path through an OSPF area, you 


cannot configure a secondary interface or a primary interface with one or more secondary interfaces to 
be passive. Passive interfaces advertise their address, but do not run the OSPF protocol (adjacencies 
are not formed and hello packets are not generated). 


Any logical interface not configured as a secondary interface for an area is treated as a primary interface 


for that area. A logical interface can be configured as the primary interface only for one area. For any 
other area for which you configure the interface, you must configure it as a secondary interface. 


e You cannot configure the secondary statement with the interface all statement. 


e You cannot configure a secondary interface by its IP address. 


Figure 7: Multiarea Adjacency in OSPF 
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In this example, you configure an interface to be in two areas, creating a multiarea adjacency with a link 
between two ABRs: ABR R1 and ABR R2. On each ABR, area 0.0.0.1 contains the primary interface and 
is the primary link between the ABRs, and area 0.0.0.2 contains the secondary logical interface, which you 
configure by including the secondary statement. You configure interface so-O0/0/0 on ABR R1 and interface 
so-1/0/0 on ABR R2. 


Configuration 


CLI Quick Configuration 

To quickly configure a secondary logical interface for an OSPF area, copy the following commands, paste 
them into a text file, remove any line breaks, change any details necessary to match your network 
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter 
commit from configuration mode. 


Configuration on ABR R1: 


[edit] 

set interfaces so-0/0/0 unit O family inet address 192.0.2.45/24 
set routing-options router-id 10.255.0.1 

set protocols ospf area 0.0.0.1 interface so-0/0/0 

set protocols ospf area 0.0.0.2 interface so-0/0/0 secondary 


Configuration on ABR R2: 
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[edit] 

set interfaces so-1/0/0 unit O family inet address 192.0.2.37/24 
set routing-options router-id 10.255.0.2 

set protocols ospf area 0.0.0.1 interface so-1/0/0 

set protocols ospf area 0.0.0.2 interface so-1/0/0 secondary 


Step-by-Step Procedure 


To configure a secondary logical interface: 


1. Configure the device interfaces. 


NOTE: For OSPFv3, on each interface specify the inet6 address family and include the IPv6 
address. 


[edit] 
user@R1# set interfaces so-0/0/0 unit O family inet address 192.0.2.45/24 


[edit] 
user@R2# set interfaces so-1/0/0 unit O family inet address 192.0.2.37/24 


2. Configure the router identifier. 


[edit] 
user@R1# set routing-options router-id 10.255.0.1 


[edit] 
user@R2# set routing-options router-id 10.255.0.2 


3. On each ABR, configure the primary interface for the OSPF area. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@R1# set protocols ospf area 0.0.0.1 interface so-0/0/0 
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[edit ] 
user@R2# set protocols ospf area 0.0.0.1 interface so-1/0/0 


4. On each ABR, configure the secondary interface for the OSPF area. 


[edit ] 
user@R1# set protocols ospf area 0.0.0.2 so-0/0/0 secondary 


[edit ] 
user@R2# set protocols ospf area 0.0.0.2 so-1/0/0 secondary 


5. If you are done configuring the devices, commit the configuration. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces, show routing-options, and the show protocols 
ospf commands. If the output does not display the intended configuration, repeat the instructions in this 
example to correct the configuration. 


Configuration on ABR R1: 


user@R1# show interfaces 
so-0/0/0 { 
unit O { 
family inet { 
address 192.0.2.45/24; 


user@R1# show routing-options 
router-id 10.255.0.1; 


user@R1# show protocols ospf 
area 0.0.0.1 { 
interface so-0/0/0.0; 


} 
area 0.0.0.2 { 
interface so-0/0/0.0 { 


secondary; 


Configuration on ABR R2: 


user@R2# show interfaces 
so-0/0/0 { 
unit O { 
family inet { 
address 192.0.2.37/24; 


user@R2# show routing-options 
router-id 10.255.0.2; 


user@R2# show protocols ospf 
area 0.0.0.1 { 
interface so-1/0/0.0; 


} 
area 0.0.0.2 { 
interface so-1/0/0.0 { 
secondary; 


Verification 


IN THIS SECTION 


@ Verifying the Secondary Interface | 90 
@ Verifying the Interfaces in the Area | 90 
@ Verifying Neighbor Adjacencies | 90 
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Confirm that the configuration is working properly. 


Verifying the Secondary Interface 


Purpose 


Verify that the secondary interface appears for the configured area. The Secondary field is displayed if 
the interface is configured as a secondary interface. The output might also show the same interface listed 
in multiple areas. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Verifying the Interfaces in the Area 


Purpose 


Verify the interfaces configured for the specified area. 


Action 


From operational mode, enter the show ospf interface area area-id command for OSPF v2, and enter the 
show ospf3 interface area area-id command for OSPFv3.. 


Verifying Neighbor Adjacencies 


Purpose 
Verify the primary and secondary neighbor adjacencies. The Secondary field displays if the neighbor is on 
a secondary interface. 


Action 


From operational mode, enter the show ospf neighbor detail command for OSPF v2, and enter the show 
ospf3 neighbor detail command for OSPFv3. 


Understanding Multiarea Adjacencies for OSPFv3 


An area is a set of networks and hosts within an OSPFv3 domain that have been administratively grouped 
together. By default, a single interface can belong to only one OSPF v3 area. However, in some situations, 
you might want to configure an interface to belong to more than one area to avoid suboptimal routing. 
Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be 
preferred over higher-cost intra-area links. 


In Junos OS Release 9.2 and later, you can configure an interface to belong to more than one OSPFv2 
area. Support for OSPFv3 was introduced in Junos OS Release 9.4. As defined in RFC 5185, OSPF Multi-Area 
Adjacency, the ABRs establish multiple adjacencies belonging to different areas over the same logical 
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interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured 
area by the routers connected to the link. 


An interface is considered to be primarily in one area. When you configure the same interface in another 
area, it is considered to be secondarily in the other area. You designate the secondary area by including 
the secondary statement at the [edit protocols ospf3 area area-number interface interface-name] hierarchy 
level. 


Example: Configuring a Multiarea Adjacency for OSPFv3 


IN THIS SECTION 


Requirements | 91 
Overview | 91 


Configuration | 92 


Verification | 98 


This example shows how to configure a multiarea adjacency for OSPFv3. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


OSPFv3 intra-area paths are preferred over inter-area paths. In this example, Device R1 and Device R2 
are area border routers (ABRs) with interfaces in both area O and in area 1. The link between Device R1 
and R2 is in area O and is a high-speed link. The links in area 1 are lower speed. 


If you want to forward some of area 1’s traffic between Device R1 and Device R2 over the high-speed 
link, one method to accomplish this goal is to make the high-speed link a multiarea adjacency so that the 
link is part of both area O and area 1. 


If the high-speed link between Device R1 and Device R2 remains in area 1 only, Device R1 always routes 
traffic to Device R4 and Device R5 through area 1 over the lower-speed links. Device R1 also uses the 
intra-area area 1 path through Device R3 to get to area 1 destinations downstream of Device R2. 


Clearly, this scenario results in suboptimal routing. 
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An OSPF virtual link cannot be used to resolve this issue without moving the link between Device R1 and 
Device R2 to area 1. You might not want to do this if the physical link belongs to the network's backbone 
topology. 


The OSPF/OSPFv3 protocol extension described in RFC 5185, OSPF Multi-Area Adjacency resolves the 
issue, by allowing the link between Device R1 and Device R2 to be part of both the backbone area and 
area 1. 


To create a multiarea adjacency, you configure an interface to be in two areas, with ge-1/2/0 on Device 
R1 configured in both area O and area 1, and ge-1/2/0 on Device R2 configured in both area O and area 
1. On both Device R1 and Device R2, area O contains the primary interface and is the primary link between 
the devices. Area 1 contains the secondary logical interface, which you configure by including the secondary 
statement. 


Figure 8: OSPFv3 Multiarea Adjacency 
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“CLI Quick Configuration” on page 92 shows the configuration for all of the devices in Figure 8 on page 92. 
The section “Step-by-Step Procedure” on page 94 describes the steps on Device R1 and Device R2. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device R1 


set interfaces ge-1/2/0 unit 0 family inet6 address 2001:db8::1/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 2001:db8::2/64 


set interfaces loO unit O family inet address 1.1.1.1/32 

set interfaces loO unit O family inet6 address 1::1/128 

set protocols ospf3 area 0.0.0.0 interface ge-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 secondary 


Device R2 


set interfaces ge-1/2/0 unit 0 family inet6 address 9009:1::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:4::1/64 
set interfaces fe-1/2/2 unit 0 family inet6 address 9009:6::2/64 
set interfaces loO unit O family inet address 2.2.2.2/32 

set interfaces loO unit O family inet6 address 2::2/128 

set protocols ospf3 area 0.0.0.0 interface ge-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/2.0 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 secondary 


Device R3 


set interfaces fe-1/2/0 unit O family inet6 address 9009:2::1/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:3::1/64 
set interfaces loO unit O family inet address 3.3.3.3/32 

set interfaces loO unit O family inet6 address 3::3/128 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.1 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 


Device R4 


set interfaces fe-1/2/0 unit O family inet6 address 9009:3::2/64 
set interfaces fe-1/2/1 unit O family inet6 address 9009:4::1/64 


set interfaces fe-1/2/2 unit O family inet6 address 9009:5::1/64 
set interfaces loO unit O family inet address 4.4.4.4/32 

set interfaces loO unit O family inet6 address 4::4/128 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.1 interface lo0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/2.0 


Device R5 


set interfaces fe-1/2/0 unit O family inet6 address 9009:5::2/64 
set interfaces loO unit O family inet address 5.5.5.5/32 

set interfaces loO unit O family inet6 address 5::5/128 

set protocols ospf3 area 0.0.0.1 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 


Device R6 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:6::2/64 
set interfaces loO unit O family inet address 6.6.6.6/32 

set interfaces loO unit O family inet6 address 6::6/128 

set protocols ospf3 area 0.0.0.1 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R1: 


1. Configure the interfaces. 


[edit interfaces] 

user@R1# set ge-1/2/0 unit 0 family inet6 address 9009:1::1/64 
user@R1# set fe-1/2/1 unit 0 family inet6 address 9009:2::2/64 
user@R1# set loO unit O family inet address 1.1.1.1/32 
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user@R1# set loO unit O family inet6 address 1::1/128 


2. Enable OSPFv3 on the interfaces that are in area O. 


[edit protocols ospf3 area 0.0.0.0] 
user@R1# set interface ge-1/2/0.0 
user@R1# set interface lo0.0 passive 


3. Enable OSPFv3 on the interface that is in area 1. 


[edit protocols ospf3 area 0.0.0.1] 
user@R1# set interface fe-1/2/1.0 
user@R1# set interface ge-1/2/0.0 secondary 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R2: 


1. Configure the interfaces. 


[edit interfaces] 

user@R2# set ge-1/2/0 unit O family inet6 address 9009:1::2/64 
user@R2# set fe-1/2/1 unit O family inet6 address 9009:4::1/64 
user@R2# set fe-1/2/2 unit O family inet6 address 9009:6::2/64 
user@R2# set loO unit O family inet address 2.2.2.2/32 
user@R2# set loO unit O family inet6 address 2::2/128 


2. Enable OSPFv3 on the interfaces that are in area O. 


[edit protocols ospf3 area 0.0.0.0] 
user@R2# set interface ge-1/2/0.0 
user@R2# set interface lo0.0 passive 


3. Enable OSPFv3 on the interface that is in area 1. 


[edit protocols ospf3 area 0.0.0.1] 
user@R2# set interface fe-1/2/2.0 
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user@R2# set interface fe-1/2/1.0 
user@R2# set interface ge-1/2/0.0 secondary 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 
to correct the configuration. 


Device R1 


user@R1# show interfaces 
ge-1/2/0 { 
unit O { 
family ineté { 
address 9009:1::1/64; 


} 
fe-1/2/1 { 
unit O { 
family ineté { 
address 9009:2::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 1.1.1.1/32; 
} 
family ineté { 
address 1::1/128; 


user@R1# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface ge-1/2/0.0; 
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interface 100.0 { 
passive; 


} 
area 0.0.0.1 { 
interface fe-1/2/1.0; 
interface ge-1/2/0.0 { 
secondary; 


Device R2 


user@R2# show interfaces 
ge-1/2/0 { 
unit O { 
family ineté { 
address 9009:1::2/64; 


} 
fe-1/2/1 { 
unit O { 
family ineté { 
address 9009:4::1/64; 


} 
fe-1/2/2 { 
unit O { 
family ineté { 
address 9009:6::2/64; 


} 
loO { 
unit O { 
family inet { 
address 2.2.2.2/32; 
} 
family ineté { 
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address 2::2/128; 


user@R2# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface ge-1/2/0.0; 
interface 100.0 { 


passive; 


} 
area 0.0.0.1 { 
interface fe-1/2/2.0; 
interface fe-1/2/1.0; 
interface ge-1/2/0.0 { 
secondary; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ Verifying the Flow of Traffic | 98 
@ ~~ Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency | 99 


Confirm that the configuration is working properly. 
Verifying the Flow of Traffic 


Purpose 
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Verify that traffic uses the high-speed link between Device R1 and Device R2 to reach destinations in area 
1. 


Action 


From operational mode on Device R1, use the traceroute command check the traffic flow to Device R5 
and Device R6. 


user@R1> traceroute 6::6 
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user@R1> traceroute 5::5 
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Meaning 


The traceroute output shows that traffic uses the 9009:1:: link between Device R1 and Device R2. 


Verifying That the Traffic Flow Changes When You Remove the Multiarea Adjacency 


Purpose 


Verify the results without the multiarea adjacency configured. 


Action 
1. Deactivate the backbone link interfaces in area 1. 


user@R1# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 
user@R1# commit 
user@R2# deactivate protocols ospf3 area 0.0.0.1 interface ge-1/2/0.0 
user@R2# commit 


2. From operational mode on Device R1, use the traceroute command check the traffic flow to Device 
R5 and Device R6. 


user@R1> traceroute 6::6 
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user@R1> traceroute 5::5 
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Without the multiarea adjacency, the output shows suboptimal routing with traffic taking the path through 


the area 1 low-speed-links. 


Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby 


Areas 


Figure 9 on page 101 shows an autonomous system (AS) across which many external routes are advertised. 


If external routes make up a significant portion of a topology database, you can suppress the advertisements 


in areas that do not have links outside the network. By doing so, you can reduce the amount of memory 


the nodes use to maintain the topology database and free it for other uses. 


Figure 9: OSPF AS Network with Stub Areas and NSSAs 
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To control the advertisement of external routes into an area, OSPF uses stub areas. By designating an area 
border router (ABR) interface to the area as a stub interface, you suppress external route advertisements 
through the ABR. Instead, the ABR advertises a default route (through itself) in place of the external routes 
and generates network summary (Type 3) link-state advertisements (LSAs). Packets destined for external 
routes are automatically sent to the ABR, which acts as a gateway for outbound traffic and routes the 
traffic appropriately. 


NOTE: You must explicitly configure the ABR to generate a default route when attached to a 
stub or not-so-stubby-area (NSSA). To inject a default route with a specified metric value into 
the area, you must configure the default-metric option and specify a metric value. 


For example, area 0.0.0.3 in Figure 9 on page 101 is not directly connected to the outside network. All 
outbound traffic is routed through the ABR to the backbone and then to the destination addresses. By 
designating area 0.0.0.3 as a stub area, you reduce the size of the topology database for that area by 
limiting the route entries to only those routes internal to the area. 


A stub area that only allows routes internal to the area and restricts Type 3 LSAs from entering the stub 
area is often called a totally stubby area. You can convert area 0.0.0.3 to a totally stubby area by configuring 
the ABR to only advertise and allow the default route to enter into the area. External routes and destinations 
to other areas are no longer summarized or allowed into a totally stubby area. 


NOTE: If you incorrectly configure a totally stubby area, you might encounter network 
connectivity issues. You should have advanced knowledge of OSPF and understand your network 
environment before configuring totally stubby areas. 
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Similar to area 0.0.0.3 in Figure 9 on page 101, area 0.0.0.4 has no external connections. However, area 
0.0.0.4 has static customer routes that are not internal OSPF routes. You can limit the external route 
advertisements to the area and advertise the static customer routes by designating the area an NSSA. In 
an NSSA, the AS boundary router generates NSSA external (Type 7) LSAs and floods them into the NSSA, 
where they are contained. Type 7 LSAs allow an NSSA to support the presence of AS boundary routers 
and their corresponding external routing information. The ABR converts Type 7 LSAs into AS external 
(Type 5 ) LSAs and leaks them to the other areas, but external routes from other areas are not advertised 
within the NSSA. 


Example: Configuring OSPF Stub and Totally Stubby Areas 


IN THIS SECTION 


Requirements | 102 
Overview | 103 
Configuration | 104 


Verification | 106 


This example shows how to configure an OSPF stub area and a totally stubby area to control the 
advertisement of external routes into an area. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 
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Overview 


The backbone area, which is O in Figure 10 on page 104, has a special function and is always assigned the 
area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only 
be unique within an autonomous system (AS). All other networks or areas (such as 3, 7, and 9) in the AS 
must be directly connected to the backbone area by area border routers (ABRs) that have interfaces in 
more than one area. 


Stub areas are areas through which or into which OSPF does not flood AS external link-state advertisements 
(Type 5 LSAs). You might create stub areas when much of the topology database consists of AS external 
advertisements and you want to minimize the size of the topology databases on the internal routers in the 
stub area. 


The following restrictions apply to stub areas: 


e You cannot create a virtual link through a stub area. 
e Astub area cannot contain an AS boundary router. 
e You cannot configure the backbone as a stub area. 


e You cannot configure an area as both a stub area and an not-so-stubby area (NSSA). 


In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some 
additional settings on the ABR: 


e stub—Specifies that this area become a stub area and not be flooded with Type 5 LSAs. You must include 
the stub statement on all routing devices that are in area 7 because this area has no external connections. 


e default-metric—Configures the ABR to generate a default route with a specified metric into the stub 
area. This default route enables packet forwarding from the stub area to external destinations. You 
configure this option only on the ABR. The ABR does not automatically generate a default route when 
attached to a stub. You must explicitly configure this option to generate a default route. 


e no-summaries—(Optional) Prevents the ABR from advertising summary routes into the stub area by 
converting the stub area into a totally stubby area. If configured in combination with the default-metric 
statement, a totally stubby area only allows routes internal to the area and advertises the default route 
into the area. External routes and destinations to other areas are no longer summarized or allowed into 
a totally stubby area. Only the ABR requires this additional configuration because it is the only routing 
device within the totally stubby area that creates Type 3 LSAs used to receive and send traffic from 
outside of the area. 


104 


NOTE: 


In Junos OS Release 8.5 and later, the following applies: 


e A router-identifier interface that is not configured to run OSPF is no longer advertised as a 
stub network in OSPF LSAs. 


e OSPF advertises a local route with a prefix length of 32 as a stub link if the loopback interface 
is configured with a prefix length other than 32. OSPF also advertises the direct route with 
the configured mask length, as in earlier releases. 


Figure 10: OSPF Network Topology with Stub Areas and NSSAs 
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CLI Quick Configuration 
e To quickly configure an OSPF stub area, copy the following command and paste it into the CLI. You 
must configure all routing devices that are part of the stub area. 


[edit] 
set protocols ospf area 07 stub 


e To quickly configure the ABR to inject a default route into the area, copy the following command and 
paste it into the CLI. You apply this configuration only on the ABR. 


[edit] 
set protocols ospf area 07 stub default-metric 10 
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e (Optional) To quickly configure the ABR to restrict all summary advertisements and allow only internal 
routes and default route advertisements into the area, copy the following command and paste it into 
the CLI. You apply this configuration only on the ABR. 


[edit] 


set protocols ospf area 0.0.0.7 stub no-summaries 


Step-by-Step Procedure 
To configure OSPF stub areas: 


1. On all routing devices in the area, configure an OSPF stub area. 


NOTE: To specify an OSPF v3 stub area, include the ospf3 statement at the [edit protocols] 
hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.7 stub 
2. On the ABR, inject a default route into the area. 
[edit] 
user@host# set protocols ospf area 0.0.0.7 stub default-metric 10 
3. (Optional) On the ABR, restrict summary LSAs from entering the area. This step converts the stub area 
into a totally stubby area. 
[edit] 
user@host# set protocols ospf area 0.0.0.7 stub no-summaries 


4. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


Configuration on all routing devices: 


user@host# show protocols ospf 
area 0.0.0.7 { 
stub; 


Configuration on the ABR (the output also includes the optional setting): 


user@host# show protocols ospf 
area 0.0.0.7 { 
stub default-metric 10 no-summaries; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 
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Confirm that the configuration is working properly. 


Verifying the Interfaces in the Area 


Purpose 


Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output 


includes Stub as the type of OSPF area. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 


ospf3 interface detail command for OSPFv3. 


Verifying the Type of OSPF Area 


Purpose 


Verify that the OSPF area is a stub area. Confirm that the output displays Normal Stub as the Stub type. 


Action 
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From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 


| Example: Configuring OSPF Not-So-Stubby Areas 
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This example shows how to configure an OSPF not-so-stubby area (NSSA) to control the advertisement 
of external routes into an area. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


The backbone area, which is O in Figure 11 on page 109, has a special function and is always assigned the 
area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only 
be unique within an AS. All other networks or areas (such as 3, 7, and 9) in the AS must be directly connected 
to the backbone area by ABRs that have interfaces in more than one area. 


An OSPF stub area has no external routes, so you cannot redistribute routes from another protocol into 
a stub area. OSPF NSSAs allow external routes to be flooded within the area. 
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In addition, you might have a situation when exporting Type 7 LSAs into the NSSA is unnecessary. When 
an AS boundary router is also an ABR with an NSSA attached, Type 7 LSAs are exported into the NSSA 
by default. If the ABR is attached to multiple NSSAs, a separate Type 7 LSA is exported into each NSSA 
by default. During route redistribution, this routing device generates both Type 5 LSAs and Type 7 LSAs. 
You can disable exporting Type 7 LSAs into the NSSA. 


NOTE: The following restriction applies to NSSAs: You cannot configure an area as both a stub 
area and an NSSA. 


You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting: 


e nssa—Specifies an OSPF NSSA. You must include the nssa statement on all routing devices in area 9 
because this area only has external connections to static routes. 


You also configure the ABR in area 9 with the following additional settings: 


e no-summaries—Prevents the ABR from advertising summary routes into the NSSA. If configured in 
combination with the default-metric statement, the NSSA only allows routes internal to the area and 
advertises the default route into the area. External routes and destinations to other areas are no longer 
summarized or allowed into the NSSA. Only the ABR requires this additional configuration because it is 
the only routing device within the NSSA that creates Type 3 LSAs used to receive and send traffic from 
outside the area. 


default-lsa—Configures the ABR to generate a default route into the NSSA. In this example, you configure 
the following: 


e default-metric—Specifies that the ABR generate a default route with a specified metric into the NSSA. 
This default route enables packet forwarding from the NSSA to external destinations. You configure 
this option only on the ABR. The ABR does not automatically generate a default route when attached 
to an NSSA. You must explicitly configure this option for the ABR to generate a default route. 


metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either 


Type 1 or Type 2. When OSPF exports route information from external ASs, it includes a cost, or 
external metric, in the route. The difference between the two metrics is how OSPF calculates the cost 
of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal 
to the sum of the internal costs plus the external cost. Type 2 external metrics use only the external 
cost assigned by the AS boundary router. By default, OSPF uses the Type 2 external metric. 


type-7—(Optional) Floods Type 7 default LSAs into the NSSA if the no-summaries statement is 


configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into 
NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos OS 
releases, include the type-7 statement. 
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The second example also shows the optional configuration required to disable exporting Type 7 LSAs into 
the NSSA by including the no-nssa-abr statement on the routing device that performs the functions of 
both an ABR and an AS boundary router. 


Figure 11: OSPF Network Topology with Stub Areas and NSSAs 
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Configuring Routing Devices to Participate in a Not-So-Stubby-Area 


CLI Quick Configuration 
To quickly configure an OSPF NSSA, copy the following command and paste it into the CLI. You must 
configure all routing devices that are part of the NSSA. 


[edit] 
set protocols ospf area 0.0.0.9 nssa 


To quickly configure an ABR that participates in an OSPF NSSA, copy the following commands and paste 
them into the CLI. 


[edit] 

set protocols ospf area 0.0.0.9 nssa default-lsa default-metric 10 
set protocols ospf area 0.0.0.9 nssa default-lsa metric-type 1 

set protocols ospf area 0.0.0.9 nssa default-lsa type-7 

set protocols ospf area 0.0.0.9 nssa no-summaries 


Step-by-Step Procedure 
To configure OSPF NSSAs: 


1. On all routing devices in the area, configure an OSPF NSSA. 


NOTE: To specify an OSPFv3 NSSA area, include the ospf3 statement at the [edit protocols] 
hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.9 nssa 


2. Onthe ABR, enter OSPF configuration mode and specify the NSSA area 0.0.0.9 that you already created. 


[edit ] 
user@host# edit protocols ospf area 0.0.0.9 nssa 


3. On the ABR, inject a default route into the area. 


[edit protocols ospf area 0.0.0.9 nssa] 
user@host# set default-Isa default-metric 10 


4. (Optional) On the ABR, specify the external metric type for the default route. 


[edit protocols ospf area 0.0.0.9 nssa] 
user@host# set default-Isa metric-type 1 


5. (Optional) On the ABR, specify the flooding of Type 7 LSAs. 


[edit protocols ospf area 0.0.0.9 nssa] 
user@host# set default-Isa type-7 
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6. On the ABR, restrict summary LSAs from entering the area. 


[edit protocols ospf area 0.0.0.9 nssa] 
user@host# set no-summaries 


7. \f you are done configuring the devices, commit the configuration. 


[edit protocols ospf area 0.0.0.9 nssa] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


Configuration on all routing devices in the area: 


user@host# show protocols ospf 
area 0.0.0.9 { 


nssa; 


Configuration on the ABR. The output also includes the optional metric-type and type-7 statements. 


user@host# show protocols ospf 
area 0.0.0.9 { 
nssa { 
default-lsa { 
default-metric 10; 
metric-type 1; 
type-7; 
} 


no-summaries; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas 


CLI Quick Configuration 

To quickly disable exporting Type 7 LSAs into the NSSA, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
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configuration mode. You configure this setting on an AS boundary router that is also an ABR with an NSSA 
area attached. 


[edit] 
set protocols ospf no-nssa-abr 


Step-by-Step Procedure 
You can configure this setting if you have an AS boundary router that is also an ABR with an NSSA area 
attached. 


1. Disable exporting Type 7 LSAs into the NSSA. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf no-nssa-abr 

2. If you are done configuring the device, commit the configuration. 
[edit] 


user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
no-nssa-abr; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 
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Confirm that the configuration is working properly. 


Verifying the Interfaces in the Area 


Purpose 


Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output 
includes Stub NSSA as the type of OSPF area. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Verifying the Type of OSPF Area 


Purpose 
Verify that the OSPF area is a stub area. Confirm that the output displays Not so Stubby Stub as the Stub 
type. 


Action 
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 


Verifying the Type of LSAs 


Purpose 
Verify the type of LSAs that are in the area. If you disabled exporting Type 7 LSAs into an NSSA, confirm 
that the Type field does not include NSSA as a type of LSA. 


Action 
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 
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| Understanding OSPFv3 Stub and Totally Stubby Areas 


Junos OS OSPF v3 configuration for IPv6 networks is identical to OSPFv2 configuration. You configure 
the protocol with set ospf3 commands instead of set ospf commands and use show ospf3 commands 
instead of show ospf commands to check the OSPF status. Also, make sure to set IPv6é addresses on the 
interfaces running OSPF v3. 


Stub areas are areas through which or into which OSPF does not flood AS external link-state advertisements 
(Type 5 LSAs). You might create stub areas when much of the topology database consists of AS external 
advertisements and you want to minimize the size of the topology databases on the internal routers in the 


stub area. 
The following restrictions apply to stub areas: 


e You cannot create a virtual link through a stub area. 
e Astub area cannot contain an AS boundary router. 
e You cannot configure the backbone as a stub area. 


e You cannot configure an area as both a stub area and an not-so-stubby area (NSSA). 


| Example: Configuring OSPFv3 Stub and Totally Stubby Areas 
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This example shows how to configure an OSPFv3 stub area and a totally stubby area to control the 
advertisement of external routes into an area. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 
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Overview 


Figure 12 on page 115 shows the topology used in this example. 


Figure 12: OSPFv3 Network Topology with Stub Areas 
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In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some 
additional settings on the ABR: 


e stub—Specifies that this area become a stub area and not be flooded with Type 5 LSAs. You must include 
the stub statement on all routing devices that are in area 7 because this area has no external connections. 


e default-metric—Configures the ABR to generate a default route with a specified metric into the stub 
area. This default route enables packet forwarding from the stub area to external destinations. You 
configure this option only on the ABR. The ABR does not automatically generate a default route when 
attached to a stub. You must explicitly configure this option to generate a default route. 


e no-summaries—(Optional) Prevents the ABR from advertising summary routes into the stub area by 
converting the stub area into a totally stubby area. If configured in combination with the default-metric 
statement, a totally stubby area only allows routes internal to the area and advertises the default route 
into the area. External routes and destinations to other areas are no longer summarized or allowed into 
a totally stubby area. Only the ABR requires this additional configuration because it is the only routing 
device within the totally stubby area that creates Type 3 LSAs used to receive and send traffic from 


outside of the area. 
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NOTE: 


In Junos OS Release 8.5 and later, the following applies: 


e A router-identifier interface that is not configured to run OSPF is no longer advertised as a 
stub network in OSPF LSAs. 


e OSPF advertises a local route with a prefix length of 32 as a stub link if the loopback interface 
is configured with a prefix length other than 32. OSPF also advertises the direct route with 
the configured mask length, as in earlier releases. 


“CLI Quick Configuration” on page 116 shows the configuration for all of the devices in Figure 12 on page 115. 
The section “Step-by-Step Procedure” on page 118 describes the steps on Device 2, Device 6, Device 7, 
and Device 8. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device 1 


set interfaces fe-1/2/0 unit O family inet6 address 9009:1::1/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:2::1/64 
set interfaces fe-1/2/2 unit 0 family inet6 address 9009:3::1/64 
set interfaces loO unit O family inet address 1.1.1.1/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf3 area 0.0.0.0 interface l|o0.0 passive 


Device 2 


set interfaces fe-1/2/0 unit O family inet6 address 9009:2::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:4::1/64 
set interfaces loO unit O family inet address 2.2.2.2/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 
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set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 
set protocols ospf3 area 0.0.0.7 stub default-metric 10 
set protocols ospf3 area 0.0.0.7 stub no-summaries 
set protocols ospf3 area 0.0.0.7 interface fe-1/2/1.0 


Device 3 


set interfaces fe-1/2/0 unit O family inet6 address 9009:3::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:5::1/64 
set interfaces loO unit O family inet address 3.3.3.3/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0 


Device 4 


set interfaces fe-1/2/0 unit O family inet6 address 9009:1::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:6::1/64 
set interfaces loO unit O family inet address 4.4.4.4/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.3 interface fe-1/2/1.0 


Device 5 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:6::2/64 
set interfaces loO unit O family inet address 5.5.5.5/32 

set protocols ospf3 area 0.0.0.3 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.3 interface |o0.0 passive 


Device 6 
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set interfaces fe-1/2/0 unit O family inet6 address 9009:4::2/64 
set interfaces loO unit O family inet address 6.6.6.6/32 

set protocols ospf3 area 0.0.0.7 stub 

set protocols ospf3 area 0.0.0.7 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.7 interface |o0.0 passive 


Device 7 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:5::2/64 

set interfaces fe-1/2/1 unit 0 family inet6 address 9009:7::1/64 

set interfaces loO unit O family inet address 7.7.7.7/32 

set protocols ospf3 export static-to-ospf 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.9 interface |o0.0 passive 

set policy-options policy-statement static-to-ospf term 1 from protocol static 
set policy-options policy-statement static-to-ospf term 1 then accept 

set routing-options rib inet6.0 static route 1010::1/128 next-hop 9009:7::2 
set routing-options rib inet6.0 static route 2020::1/128 next-hop 9009:7::2 


Device 8 


set interfaces fe-1/2/0 unit O family inet6 address 9009:7::2/64 
set interfaces loO unit O family inet address 8.8.8.8/32 

set interfaces loO unit 0 family inet6 address 1010::1/128 

set interfaces loO unit O family inet6 address 2020::1/128 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 2: 


1. Configure the interfaces. 


[edit interfaces] 
user@2# set fe-1/2/0 unit 0 family inet6 address 9009:2::2/64 


user@2# set fe-1/2/1 unit 0 family inet6 address 9009:4::1/64 
user@2# set loO unit O family inet address 2.2.2.2/32 


2. Enable OSPFv3 on the interfaces that are in area O. 


[edit protocols ospf3 area 0.0.0.0] 
user@2# set interface fe-1/2/0.0 
user@2# set interface lo0.0 passive 


3. Enable OSPFv3 on the interface that is in area 7. 


[edit protocols ospf3 area 0.0.0.7] 
user@2# set interface fe-1/2/1.0 


4. Specify area 7 as an OSPFv3 stub area. 


The stub statement is required on all routing devices in the area. 


[edit protocols ospf3 area 0.0.0.7] 
user@2# set stub 


5. On the ABR, inject a default route into the area. 


[edit protocols ospf3 area 0.0.0.7] 
user@2# set stub default-metric 10 


6. (Optional) On the ABR, restrict summary LSAs from entering the area. 


This step converts the stub area into a totally stubby area. 


[edit protocols ospf3 area 0.0.0.7] 
user@2# set stub no-summaries 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 6: 


1. Configure the interfaces. 
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[edit interfaces] 
user@6# set fe-1/2/0 unit 0 family inet6 address 9009:4::2/64 
user@6# set loO unit O family inet address 6.6.6.6/32 


2. Enable OSPFv3 on the interface that is in area 7. 


[edit protocols ospf3 area 0.0.0.7] 
user@6# set interface fe-1/2/0.0 
user@6# set interface lo0.0 passive 


3. Specify area 7 as an OSPFv3 stub area. 


The stub statement is required on all routing devices in the area. 


[edit protocols ospf3 area 0.0.0.7] 
user@6# set stub 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 7: 


1. Configure the interfaces. 


[edit interfaces] 

user@7# set fe-1/2/0 unit 0 family inet6 address 9009:5::2/64 
user@7# set fe-1/2/1 unit 0 family inet6 address 9009:7::1/64 
user@7# set loO unit O family inet address 7.7.7.7/32 


2. Enable OSPFv3 on the interface that is in area 9. 


[edit protocols ospf3 area 0.0.0.9] 
user@7# set interface fe-1/2/0.0 
user@7# set interface lo0.0 passive 


3. Configure static routes that enable connectivity to the customer routes. 


[edit routing-options rib inet6.0 static] 


user@7# set route 1010::1/128 next-hop 9009:7::2 
user@7# set route 2020::1/128 next-hop 9009:7::2 


4. Configure a routing policy to redistribute the static routes. 


[edit policy-options policy-statement static-to-ospf term 1] 
user@7# set from protocol static 
user@7# set then accept 


5. Apply the routing policy to the OSPFv3 instance. 


[edit protocols ospf3] 
user@7# set export static-to-ospf 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 8: 


1. Configure the interfaces. 


[edit interfaces] 
user@8# set fe-1/2/0 unit O family inet6 address 9009:7::2/64 
user@8# set lo0 unit 0 family inet address 8.8.8.8/32 


2. Configure two loopback interface addresses to simulate customer routes. 


[edit interfaces loO unit O family inet6] 
user@8# set address 1010::1/128 
user@8# set address 2020::1/128 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


Device 2 
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user@2# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:2::2/64; 


} 
fe-1/2/1 { 
unit O { 
family ineté { 
address 9009:4::1/64; 


} 
lo0 { 
unit O { 
family inet { 
address 2.2.2.2/32; 


user@2# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


} 

area 0.0.0.7 { 
stub default-metric 10 no-summaries; 
interface fe-1/2/1.0; 


Device 6 
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user@6# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:4::2/64; 


} 
1o0 { 
unit O { 
family inet { 
address 6.6.6.6/32; 


user@6# show protocols 
ospf3 { 
area 0.0.0.7 { 
stub; 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


Device 7 


user@7# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:5::2/64; 


} 
re-d2/4"} 


123 


unit O { 
family ineté { 
address 9009:7::1/64; 


} 
lo0 { 
unit O { 
family inet { 
address 7.7.7.7/32; 


user@7# show protocols 
ospf3 { 
export static-to-ospf; 
area 0.0.0.9 { 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


user@7# show policy-options 
policy-statement static-to-ospf { 
term 1 { 
from protocol static; 
then accept; 


user@7# show routing-options 
rib inet6.0 { 
static { 
route 1010::1/128 next-hop 9009:7::2; 
route 2020::1/128 next-hop 9009:7::2; 
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Device 8 


user@8# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:7::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 8.8.8.8/32; 
} 
family ineté { 
address 1010::1/128; 
address 2020::1/128; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Verifying the Type of OSPFv3 Area | 125 
@ Verifying the Routes in the OSPFv3 Stub Area | 127 


Confirm that the configuration is working properly. 


Verifying the Type of OSPFv3 Area 


Purpose 
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Verify that the OSPFv3 area is a stub area. Confirm that the output displays Stub as the Stub type. 


Action 


From operational mode on Device 2 and on Device 6, enter the show ospf3 overview command. 


user@2> show ospf3 overview 


Instance: Master 
omecie IDS 2o2.2 528 
Route table index: 51 


Area border router 





LSA refresh time: 50 minutes 
Area: 0.0.0.0 
Stub type: Not Stub 





Area border routers: 2, AS boundary routers: 0 
Neighbors 
Up (in full state): 1 
Area: 0.0.0.7 
Stub type: Stub, Stub cost: 10 





Area border routers: 0, AS boundary routers: 0 
Neighbors 
Ue (aim ill Sietess) se al 
Topology: default (ID 0) 
Prefix export count: 0 
GULL Sis rpms 24 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


user@6> show ospf3 overview 


iiisizcne Cleeinalsie cits 
RowEe LD 6.6.6.6 
Route table index: 46 
LSA refresh time: 50 minutes 
Meee O.0,0.7 
Stub type: Stub 





Area border routers: 1, AS boundary routers: 0 
Neighbors 
Ue (ain iw siterese) 3 a 
Topology: default (ID 0) 
Prefix export count: 0 
ULI Sires wpmss IL7/ 
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SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


Meaning 


On Device 2, the stub type of area O is Not Stub. The stub type of area 7 is Stub. The stub default metric 
is 10. 


On Device 6, the stub type of area 7 is Stub. 


Verifying the Routes in the OSPFv3 Stub Area 


Purpose 


Make sure that the expected routes are present in the routing tables. 


Action 


From operational mode on Device 6 and Device 2, enter the show route command. 


user@6> show route 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


6.6.8 06/ 32 [Dales /O]] ikel Oils S7 31.2 


> wie illo .0 


inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 

::/0 ZAOSEH Sys RON OWE yO 5 27 memic terascuslels 
> wile ce-1/2/0.0 

9009:4::/64 == (Dalseeeic /O)]] ikel Wi eSiGe Sl 


> via fe-1/2/0.0 
OSi27'3/ iLO) el OlseSos 3, metcicie il 
> via fe-1/2/0.0 





QIOID ease B/ LAS & [ityereel/@)]) ikel Mig SGeas 
Local via fe-1/2/0.0 
fe80::/64 Dates / Oy] ile! Oils S69 Sa 





S Wile we—1/ 2/0 .0 
fe80::2a0:a514:0:a4c/128 
2 Inexeeul /@)]) tkel Oils Soe 53) 
Local via fe-1/2/0.0 


££02::5/128 SLOSETS/sk0)] 
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llcl OLeSSs22, wivsiewse: i 


MultiRecv 


user@2> show route 


inet.0: 1 destinations, 








+ = Active Route, 


Bs BoB Bi 32 * [Direct/0] 


= wile Ilo). 


inet6.0: 14 destinations, 








+ = Active Route, 


* 


1010::1/128 
> via 


* 


2020::1/128 
> via 


HOON Le 3/4 * OSPR S/ 10] 


> via 


MOOS A3 3/4 * [Direct/0] 


> via 
OSPF3/10] 
> via 


* 


9009:2::2/128 Local/0] 


Local 


9009:3::/64 * [OSPF3/10] 


> via 


9009:4::/64 * [Direct/0] 


> via 
OSPF3/10] 
> via 


9009:4::1/128 * [Local/0] 


Local 


9009:5::/64 AIOSPH 3 /s80) 


> via 


9009:6::/64 PAOSBHS// 150) 


> via 


fe80::/64 * [Direct/0 


> via 








Direct/0 





> via 


1 routes 


Last Active, 


17 routes 


Last Active, 


OSPF3/150] 
tel 2/ 0. 
OSPF3/150] 
te / 2/0. 


(aecrinie, 0 hidden) 


= Both 


0 holddown, 


* 


cl O28 i163 3} 
0 
0 holddown, 


(14 active, 0 hidden) 


= = JE¥ene lay 


OOS ORNSSr, 
0 
“302 ko, 
0 


icl OAg 183 54, 


metric 0, tag 0 


00 metric 0, tag 0 


Metaeus 


fe-1/2/0.0 


icl MAL Ss 54 


fe-1/2/0.0 


iicl O21 354. imeicrie@ i 


fe-1/2/0.0 


igl O25 ise aa 


via fe-1/2/0.0 


itcl O2s15954, imeAcmie 2 


fe-1/2/0.0 


Ich W2 ei S354 


FHL / 2 


OS8S8eOS, wrerciesye il 


t= 1/2/30 


igl O26 136 54 


Wiha i= /2/ 11.0) 


licl OF eilSsS4, wieecne 3 


fe-1/2/0.0 


itel OLSSselO, wereieie FS 


fe-1/2/0.0 


icl W2gi15¢54 


FHL / 2/0. 6 





ick (2 EL S354 


ee /i2y/ell0) 


129 


fe80::2a0:a514:0:64c/128 
J hocall//0))MilicsO 2s oo) 
Local via fe-1/2/0.0 
fe80::2a0:a514:0:94c/128 
“[Local/@]) Icl O22,ilacs4 
Hocale vale il/2)/ ln) 
EOL Se 95/128 S(OSePE3/ LO] Ikcl O2sil7sa5s, wmeicene AL 
MultiRecv 





Meaning 

On Device 6, the default route has been learned because of the default-metric statement on the ABR, 
Device 2. Otherwise, the only OSPFv3 routes in Device 6’s routing table are the network address 
9009:4::/64 and the OSPFv3 multicast address ff02::5/128 for all SPF link-state routers, also known as 
AllSPFRouters. 


On Device 2, all of the OSPFv3 routes have been learned, including the external customer routes, 
1010::1/128 and 2020::1/128. 


| Understanding OSPFv3 Not-So-Stubby Areas 


Like an OSPF stub area, an OSPFv3 stub area has no external routes, so you cannot redistribute routes 
from another protocol into a stub area. Not-so-stubby-areas (NSSAs) allow external routes to be flooded 
within the area. Routers in an NSSA do not receive external link-state advertisements (LSAs) from area 
border routers (ABRs), but are allowed to send external routing information for redistribution. They use 
type 7 LSAs to tell the ABRs about these external routes, which the ABR then translates to type 5 external 
LSAs and floods as normal to the rest of the OSPF network. 


| Example: Configuring OSPFv3 Not-So-Stubby Areas 


IN THIS SECTION 


@ = Requirements | 130 
@ = Overview | 130 

@® = Configuration | 131 
@ Verification | 141 
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This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) to control the advertisement 
of external routes into the area. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


In this example, Device 7 redistributes static Customer 1 routes into OSPFv3. Device 7 is in area 9, which 
is configured as an NSSA. Device 3 is the ABR attached to the NSSA. An NSSA is a type of stub area that 
can import autonomous system external routes and send them to other areas, but still cannot receive 
AS-external routes from other areas. Because area 9 is defined as an NSSA, Device 7 uses type 7 LSAs to 
tell the ABR (Device 3) about these external routes. Device 3 then translates the type 7 routes to type 5 
external LSAs and floods them as normal to the rest of the OSPF network. 


In area 3, Device 5 redistributes static Customer 2 routes into OSPFv3. These routes are learned on Device 
3, but not on Device 7 or 10. Device 3 injects a default static route into area 9 so that Device 7 and 10 
can still reach the Customer 2 routes. 


You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting: 
e nssa—Specifies an OSPFv3 NSSA. You must include the nssa statement on all routing devices in area 9. 


You also configure the ABR in area 9 with the following additional settings: 


no-summaries—Prevents the ABR from advertising summary routes into the NSSA. If configured in 
combination with the default-metric statement, the NSSA only allows routes internal to the area and 
advertises the default route into the area. External routes and destinations to other areas are no longer 
summarized or allowed into the NSSA. Only the ABR requires this additional configuration because it is 
the only routing device within the NSSA that creates Type 3 summary LSAs used to receive and send 
traffic from outside the area. 


default-lsa—Configures the ABR to generate a default route into the NSSA. In this example, you configure 
the following: 


e default-metric—Specifies that the ABR generate a default route with a specified metric into the NSSA. 
This default route enables packet forwarding from the NSSA to external destinations. You configure 
this option only on the ABR. The ABR does not automatically generate a default route when attached 
to an NSSA. You must explicitly configure this option for the ABR to generate a default route. 


metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either 


Type 1 or Type 2. When OSPFv3 exports route information from external ASs, it includes a cost, or 
external metric, in the route. The difference between the two metrics is how OSPFv3 calculates the 
cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is 
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equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the 
external cost assigned by the AS boundary router. By default, OSPFv3 uses the Type 2 external metric. 


e type-7—(Optional) Floods Type 7 default LSAs into the NSSA if the no-summaries statement is 
configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into 
NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos OS 
releases, include the type-7 statement. 


Figure 13: OSPFv3 Network Topology with an NSSA 
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“CLI Quick Configuration” on page 131 shows the configuration for all of the devices in Figure 13 on page 131. 


The section “Step-by-Step Procedure” on page 134 describes the steps on Device 3, Device 7, and Device 
9. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device 1 
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set interfaces fe-1/2/0 unit O family inet6 address 9009:1::1/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:3::1/64 
set interfaces loO unit O family inet address 1.1.1.1/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.5 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 


Device 3 


set interfaces fe-1/2/0 unit O family inet6 address 9009:3::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:5::1/64 
set interfaces loO unit O family inet address 3.3.3.3/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface lo0.0 passive 

set protocols ospf3 area 0.0.0.9 nssa default-Isa default-metric 10 
set protocols ospf3 area 0.0.0.9 nssa default-Isa metric-type 1 

set protocols ospf3 area 0.0.0.9 nssa default-Isa type-7 

set protocols ospf3 area 0.0.0.9 nssa no-summaries 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0 


Device 4 


set interfaces fe-1/2/0 unit O family inet6 address 9009:1::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:6::1/64 
set interfaces loO unit O family inet address 4.4.4.4/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 

set protocols ospf3 area 0.0.0.3 interface fe-1/2/1.0 


Device 5 


set interfaces fe-1/2/0 unit O family inet6 address 9009:6::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:7::1/64 
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set interfaces loO unit O family inet address 5.5.5.5/32 

set protocols ospf3 export static-to-ospf 

set protocols ospf3 area 0.0.0.3 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.3 interface |o0.0 passive 

set policy-options policy-statement static-to-ospf term 1 from protocol static 
set policy-options policy-statement static-to-ospf term 1 then accept 

set routing-options rib inet6.0 static route 1010::1/128 next-hop 9009:7::2 
set routing-options rib inet6.0 static route 2020::1/128 next-hop 9009:7::2 


Device 7 


set interfaces fe-1/2/0 unit O family inet6 address 9009:8::1/64 

set interfaces fe-1/2/1 unit 0 family inet6 address 9009:9::1/64 

set interfaces loO unit O family inet address 7.7.7.7/32 

set protocols ospf3 export static2-to-ospf 

set protocols ospf3 area 0.0.0.9 nssa 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.9 interface |o0.0 passive 

set policy-options policy-statement static2-to-ospf term 1 from protocol static 
set policy-options policy-statement static2-to-ospf term 1 then accept 

set routing-options rib inet6.0 static route 3030::1/128 next-hop 9009:8::2 
set routing-options rib inet6.0 static route 4040::1/128 next-hop 9009:8::2 


Device 8 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:7::2/64 
set interfaces loO unit O family inet address 8.8.8.8/32 

set interfaces loO unit O family inet6 address 1010::1/128 

set interfaces loO unit O family inet6 address 2020::1/128 


Device 9 


set interfaces fe-1/2/0 unit O family inet6 address 9009:8::2/64 
set interfaces loO unit O family inet address 9.9.9.9/32 


set interfaces loO unit O family inet6 address 3030::1/128 
set interfaces loO unit O family inet6 address 4040::1/128 


Device 10 


set interfaces fe-1/2/0 unit O family inet6 address 9009:5::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:9::2/64 
set interfaces loO unit O family inet address 10.10.10.10/32 

set protocols ospf3 area 0.0.0.9 nssa 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0 

set protocols ospf3 area 0.0.0.9 interface |o0.0 passive 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 3: 


1. Configure the interfaces. 
[edit interfaces] 
user@3# set fe-1/2/0 unit 0 family inet6 address 9009:3::2/64 


user@3# set fe-1/2/1 unit 0 family inet6 address 9009:5::1/64 
user@3# set loO unit O family inet address 3.3.3.3/32 


2. Enable OSPFv3 on the interfaces that are in area O. 


[edit protocols ospf3 area 0.0.0.0] 
user@3# set interface fe-1/2/0.0 
user@3# set interface lo0.0 passive 


3. Enable OSPFv3 on the interface that is in area 9. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set interface fe-1/2/1.0 
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4. Configure an OSPFv3 NSSA. 


The nssa statement is required on all routing devices in the area. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set nssa 


5. On the ABR, inject a default route into the area. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set default-Isa default-metric 10 


6. (Optional) On the ABR, specify the external metric type for the default route. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set nssa default-Isa metric-type 1 


7. (Optional) On the ABR, specify the flooding of Type 7 LSAs. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set nssa default-Isa type-7 


8. On the ABR, restrict summary LSAs from entering the area. 


[edit protocols ospf3 area 0.0.0.9] 
user@3# set nssa no-summaries 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 5: 


1. Configure the interfaces. 


[edit interfaces] 

user@5# set fe-1/2/0 unit 0 family inet6 address 9009:6::2/64 
user@5# set fe-1/2/1 unit 0 family inet6 address 9009:7::1/64 
user@5# set loO unit 0 family inet address 5.5.5.5/32 


2. Enable OSPFv3 on the interface that is in area 3. 


[edit protocols ospf3 area 0.0.0.3] 
user@5# set interface fe-1/2/0.0 
user@5# set interface lo0.0 passive 


3. Configure static routes that enable connectivity to the customer routes. 


[edit routing-options rib inet6.0 static] 
user@5# set route 1010::1/128 next-hop 9009:7::2 
user@5# set route 2020::1/128 next-hop 9009:7::2 


4. Configure a routing policy to redistribute the static routes. 


[edit policy-options policy-statement static-to-ospf term 1] 
user@5# set from protocol static 
user@5# set then accept 


5. Apply the routing policy to the OSPFv3 instance. 


[edit protocols ospf3] 
user@5# set export static-to-ospf 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 7: 


1. Configure the interfaces. 


[edit interfaces] 

user@7# set fe-1/2/0 unit 0 family inet6 address 9009:5::2/64 
user@7# set fe-1/2/1 unit O family inet6 address 9009:7::1/64 
user@7# set loO unit O family inet address 7.7.7.7/32 


2. Enable OSPFv3 on the interface that is in area 9. 


[edit protocols ospf3 area 0.0.0.9] 
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user@7# set interface fe-1/2/0.0 
user@7# set interface lo0.0 passive 


3. Configure an OSPFv3 NSSA. 


The nssa statement is required on all routing devices in the area. 


[edit protocols ospf3 area 0.0.0.9] 
user@7# set nssa 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 8: 


1. Configure the interfaces. 


[edit interfaces] 
user@8# set fe-1/2/0 unit 0 family inet6 address 9009:7::2/64 
user@8# set loO unit 0 family inet address 8.8.8.8/32 


2. Configure two loopback interface addresses to simulate customer routes. 


[edit interfaces loO unit O family inet6] 
user@8# set address 1010::1/128 
user@8# set address 2020::1/128 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


Device 3 


user@3# show interfaces 
fe-1/2/0 { 
unit O { 


family ineté { 
address 9009:3::2/64; 


} 
fe-1/2/1 { 
unit O { 
family ineté { 
address 9009:5::1/64; 


} 
lo0 { 
unit O { 
family inet { 
address 3.3.3.3/32; 


user@3# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


} 
area 0.0.0.9 { 
nssa { 
default-Isa { 
default-metric 10; 
metric-type 1; 
type-7; 
} 
no-summaries; 


} 
interface fe-1/2/1.0; 
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Device 5 


user@5# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:6::2/64; 


} 
fe-1/2/1 { 
unit O { 
family ineté { 
address 9009:7::1/64; 


} 
loO { 
unit O { 
family inet { 
address 5.5.5.5/32; 


user@5# show protocols 
ospf3 { 
export static-to-ospf; 
area 0.0.0.3 { 
interface fe-1/2/0.0; 
interface 100.0 { 
passive; 


user@5# show policy-options 
policy-statement static-to-ospf { 
term 1 { 
from protocol static; 
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then accept; 


user@5# show routing-options 
rib inet6.0 { 
static { 
route 1010::1/128 next-hop 9009:7::2; 
route 2020::1/128 next-hop 9009:7::2; 


Device 7 


user@7# show interfaces 
fe-1/2/0 { 
unit Of 
family ineté { 
address 9009:5::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 7.7.7.7/32; 


user@7# show protocols 
ospf3 { 
area 0.0.0.9 { 
nssa; 
interface fe-1/2/0.0; 
interface 100.0 { 
passive; 
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Device 8 


user@8# show interfaces 
fe-1/2/0 { 
unit O { 
family ineté { 
address 9009:7::2/64; 


} 
1o0 { 
unit O { 
family inet { 
address 8.8.8.8/32; 
} 
family ineté { 
address 1010::1/128; 
address 2020::1/128; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Verifying the Type of OSPFv3 Area | 141 
@ Verifying the Routes in the OSPFv3 Stub Area | 143 
@ Verifying the Type of LSAs | 147 


Confirm that the configuration is working properly. 


Verifying the Type of OSPFv3 Area 


Purpose 
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Verify that the OSPFv3 area is an NSSA area. Confirm that the output displays Stub NSSA as the Stub 
type. 


Action 


From operational mode on Device 3, Device 7, and Device 10 enter the show ospf3 overview command. 


user@3> show ospf3 overview 


instance, Master 
Roulcee IDG SSeSoS 
Route table index: 36 





Area border router, AS boundary router, NSSA router 
LSA refresh time: 50 minutes 
AGGAS O.0.0.0 

Stub type: Not Stub 





Area border routers: 2, AS boundary routers: 0 
Neighbors 
Uj (aim awl gitatcS)) 2 i 
Meeae 050,059) 
Stub type: Stub NSSA, Stub cost: 10 





Area border routers: 0, AS boundary routers: 1 
Neighbors 
ja (Gin wll gitatce)) 2s I 
Topology: default (ID 0) 
Prefix export count: 0 
PULL SR mums 22 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


user@7> show ospf3 overview 


Miisizane Caemnalciec ts 
Rewmece IDS Footed 
Route table index: 44 
AS boundary router, NSSA router 
LSA refresh time: 50 minutes 
mreag O.050.9 
Stub type: Stub NSSA 


Area border routers: 1, AS boundary routers: 1 





Neighbors 
Us (am uli stare) s 1 
Topology: default (ID 0) 


Prefix export count: 2 


142 


inulil Siwy wimg e ILal 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


user@10> show ospf3 overview 


Miisizcie Ctamitalsie crs 
Roweer Ws LO 10. 10.10 
Route table index: 55 
NSsA router 
LSA refresh time: 50 minutes 
Meeae W50>,0.9) 
Stub type: Stub NSSA 





Area border routers: 1, AS boundary routers: 2 
Neighbors 
Ue (aim awl staces) 3 2 
Topology: default (ID 0) 
Prefix export count: 0 
Wil SPE cuss 6 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


Meaning 


On Device 3, the stub type of area O is Not Stub. The stub type of area 9 is Stub NSSA. The stub default 
metric is 10. 


On Device 7 and Device 10, the stub type of area 9 is Stub NSSA. 


Verifying the Routes in the OSPFv3 Stub Area 


Purpose 


Make sure that the expected routes are present in the routing tables. 


Action 


From operational mode on Device 7 and Device 3, enter the show route command. 


user@7> show route 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


Tatts to ti 32 ‘a Dibaeete) Olsdm OS 0 023 
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> via 100.0 


inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


wad) *(OSETS/I150]) Wils@ilesil, meee 12, tac O 
2 Wie #e-1/2/1.0 
SOS08 31/128 a leSitechtepinc ga] mm OulesOhecE 4s 
SiO QOOIM3s8ss2 wale 1S—1/2/0 0 
4040::1/128 a lSitechterinc/g5 a] mm Orle:sOnecr 4s 
> to S009s8ss2 wila te-1/2/0.0 
9009:5::/64 OSE S/skO i Ores OnlertS Spammers skeen, 
S wile we /2/1.0 
9009:8::/64 *[Direct/0] 01:01:43 
> via f£eqi/2// 070 
9009:8::1/128 =| Oe /Oi] OleoxzsOaL 
sfofer- el Mah sit Wan Saal ly W010) 
TOO ko nc aay Alo = (Daescic/ 0] @ilsoOileas 
S Wie #e-1/2/1.0 
OSPF3/10] 01:01:44, metric 1 
S wile ee-1/2/1 40 
YOOSe 9s gi /i12s ‘aoe all/AOs|e OneO 2c Ol 
WoOcal Wie reH1/2/1.0 
£e80::/64 *[Dairect/0] 01:01:45 
2S Wie we-1/2/1.0 
Dawaecie/O)]| Ol sO eis} 
PS via £eq1/2// 00 
fe80::2a0:a514:0:f4c/128 
*[local/0] 01:02:01 
Local via fe-1/2/0.0 
fe80::2a0:a514:0:114c/128 
OSE / Oi) Oil sO2o(0aL 
Oe allelic —le/e2h/eilue0) 
MEDALS 9H/128 “(OS2 5/10] Sel OSSOIs25, meicene 1 
MultiRecv 














user@10> show route 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


10.10.10 .LO/ 32 “(Direct /0]] OilsOls So 


Panta ol 0 a0) 


inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


cace/a0) 


3030 


4040 


9009: 


9009 


9009: 


9009 


fe80: 


fesg0: 


fes0: 


16160), 8 


“(OSETS/I5O] Ole@iles5, mecrcile lil, tag O 
SS wile: eH / 2/0) .0 


3 L/L =(OSETS/150] OlsOilegsS, meine WO, ice O 


Save ine la) 20/slee) 


Sf AZ “[OS23/ 150] OleOiless, wmeceie 0, cag O 


2 Wile #e-1/2/1.0 

7/64 *([Direct/0] 01:01:50 

> wie £e-1/2/0.0 

OS27'3/ 10] OilsOlLsSO, merece i 
> via feri/ 2/020 


He so 2/i128 | bCeeL//O || Oil s@ie 50 


Local via fe-1/2/0.0 

7/64 *([Dairect/ 0] 01:00:50 

> Wile we—1/2/1.0 

OSPF3/10] 01:01:40, metric 1 
> we Le-1/2/1.€ 


QeoP file “LOGE /Oi] OleOle SC 


Local via fe-1/2/1.0 


waa | Dameecr/ || @ilsoie so 


Dan tal = Wa = ol Wy OO) 
Dalescis /(0]) Mls Oils SO 
> via fe-1/2/1.0 











22a0:a514:0:c4c/128 


= (IL@eal/@ OleOle 5O0) 
Local via fe-1/2/0.0 


S2A0saARLACO IPAS /ILZE 


* [ILKOGal/ Oi) CilLs@i.s So) 
Local via fe-1/2/1.0 


8B 23) FOSEHS// 150) MOE Os a6) wer citerest cael 


MultiRecv 


user@3> show route 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


3s3a303/ 32 * aLeereic/0)]] Sel OSs0s3 10 


> via 100.0 
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ineté. 


0: 15 destinations, 18 routes (15 active, 0 holddown, O hidden) 


+ = Active Route, - = Last Active, * = Both 


ALO MEOE: 
ZOZ0r 
S0s0r 
4040: 
9009: 


TOO: 


9009: 


9009: 


9009: 


TOOT: 


TOO: 


fes0: 


fes0: 


fe80: 


1616 (0), 8 


Meaning 


o/s *(OSPE3/ 150) 02042217 metric 0, tag 0 


> via fe-1/2/0.0 


71/128 (OSES /150]) Wils@Ag2il, ierniesice WO, ier 0 


S wie te-1/ 2/00 


L/S} “(OSES /i150] Oles@seS7, macele O, cag O 


> via fe-1/2/1.0 








cle/EZS, “(OS2T3/i150] OleO@seS7, mecele 0, cag O 


> Wile we-—1/2/1.0 

23 G4 “(OSes 3/ LO] Scl OSSO2L3OG, weceie 2 
Sacre /.27/40rn0 

7/64 ‘a Diereet/ Olmesce Os Oe oD 

> via fe-1/2/0.0 

OSPEHS/ Ole scl OC 0 277547 eeme tase ll 
> wie £6-1/2/0.0 

eg 2/128 ~([ie@cail/O] Scl OS302255 

Local via fe-1/2/0.0 

a9 Gal *[Direct/0] 01:04:09 

> via feri/2/1.0 

OSes / iLO] OlsOAsOs, imsieieae i 

2S Wile we-1/2/1.0 

eg il /il2e “([t@cal/Oi scl OS302854 

Wecal Wie weal /2/ iL. 0 

89 fel =(OS2P3 LO) Sel O2sisSola, imesiciwene 3} 
> via fe-1/2/0.0 

2/64 FLOSE RS) OMe OLe O02) metas cme 

S wie #e-1/2/1.0 


:/64 = (Dalesee/O] Sel OS8O02255 


> via fe-1/2/0.0 
Diseece/OlmmOlesO4s09 
> via fe-1/2/1.0 














22a0:a514:0:84c/128 


LOC /Oj| Sel OSS02s55 
Local via fe-1/2/0.0 


IPA ZAI si) ciole/1 Le 


“LOSE / Oi) Sel OSsO2e al 
Local via fe-1/2/1.0 


85/23) POSER S)/ ON Mec cl Oss0S) 510) meme teratsc nl: 


MultiRecv 
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On Device 7, the default route has been learned because of the default-metric statement on the ABR, 
Device 3. Otherwise, the only OSPFv3 routes in Device 7’s routing table are those local to area 9 and the 
OSPF v3 multicast address ff02::5/128 for all SPF link-state routers, also known as AllSPFRouters. 


Device 10 has the default route injected by Device 3 and also the OSPF external routes injected by Device 
7. 


Neither Device 7 nor Device 10 has the external customer routes that were injected into OSPFv3 by 
Device 5. 


On Device 3, all of the OSPFv3 routes have been learned, including the external customer routes, 
1010::1/128 and 2020::1/128. 


Verifying the Type of LSAs 


Purpose 


Verify the type of LSAs that are in the area. 


Action 


From operational mode on Device 7, enter the show ospf3 database nssa detail command. 


user@7> show ospf3 database nssa detail 


meee O.050.9 
Type ID Adv Rtr Seq Age Cksum Len 
NSSA OPOm One: Seo ses) 0x8000002a 1462 Oxf406 28 
iPmeibise 99 //0) 
Prefix-options 0x0, Metric 10, Type 1, 
NSSA =0,0 605i eto ted 0x80000003 1625 Ox88df 60 
Prefix 3030::1/128 
Prefix-options 0x8, Metric 0, Type 2, 
intel auckclhe QOOVRs sil, 
NSSA “00.052 hed Ud 0x80000003 1025 Oxef57 60 
Prefix 40403:1/128 
Prefix-options 0x8, Metric 0, Type 2, 
inigicl aelche DOME Ys oil, 


Meaning 


On Device 7, the NSSA LSAs are the type 1 external default route, learned from Device 3, and the type 2 
external static routes to the Customer 1 network. 
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| Understanding Not-So-Stubby Areas Filtering 


You might have a situation when exporting Type 7 LSAs into a not-so-stubby area (NSSA) is unnecessary. 
When an autonomous system boundary router (ASBR) is also an area border router (ABR) with an NSSA 
attached, Type 7 LSAs are exported into the NSSA by default. 


Also, when the ASBR (also an ABR) is attached to multiple NSSAs, a separate Type 7 LSA is exported into 
each NSSA by default. During route redistribution, this routing device generates both Type 5 LSAs and 
Type 7 LSAs. Hence, to avoid the same route getting redistributed twice (from Type 5 LSAs and Type 7 
LSAs), you can disable exporting Type 7 LSAs into the NSSA by including the no-nssa-abr statement on 
the routing device. 


| Example: Configuring OSPFv3 Not-So-Stubby Areas with Filtering 


IN THIS SECTION 


Requirements | 148 
Overview | 148 
Configuration | 149 


Verification | 155 


This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) when there is no need to 
inject external routes into the NSSA as Type 7 link-state advertisements (LSAs). 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


When an autonomous system border router (ASBR) is also an NSSA area border router (ABR), the routing 
device generates Type 5 as well as Type 7 LSAs. You can prevent the router from creating Type 7 LSAs 
for the NSSA with the no-nssa-abr statement. 


In this example, Device 5 and Device 3 are in customer networks. Device 4 and Device 2 are both injecting 
the customer routes into OSPFv3. Area 1 is an NSSA. Because Device 4 is both an NSSA ABR and an 
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ASBR, it generates both type 7 and type 5 LSAs and injects type 7 LSAs into area 1 and type 5 LSAs into 
area 0. To stop type 7 LSAs from being injected into area 1, the no-nssa-abr statement in included in the 


Device 4 configuration. 


Figure 14: OSPFv3 Network Topology with an NSSA ABR That Is Also an ASBR 


10/10:1/128 
20/20:1/128 
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A 2 Fs | ie 







9009:6::x/64 9009:5::x/64 
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A 
fe-1/2/2 fe-1/2/1 
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3030::1/128 
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“CLI Quick Configuration” on page 149 shows the configuration for all of the devices in Figure 14 on page 149. 
The section “Step-by-Step Procedure” on page 151 describes the steps on Device 4. 


Configuration 


CLI Quick Configuration 
To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 


the commands into the CLI at the [edit] hierarchy level. 


Device 1 


set interfaces fe-1/2/0 unit O family inet6 address 9009:6::2/64 
set interfaces fe-1/2/1 unit O family inet6 address 9009:5::1/64 
set interfaces loO unit O family inet address 1.1.1.1/32 

set protocols ospf3 area 0.0.0.1 nssa 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 
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set protocols ospf3 area 0.0.0.1 interface lo0.0 passive 


Device 2 


set interfaces fe-1/2/0 unit O family inet6 address 9009:5::2/64 

set interfaces fe-1/2/1 unit 0 family inet6 address 9009:4::1/64 

set interfaces loO unit O family inet address 2.2.2.2/32 

set protocols ospf3 export static2-to-ospf 

set protocols ospf3 area 0.0.0.1 nssa 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.1 interface |o0.0 passive 

set policy-options policy-statement static2-to-ospf term 1 from protocol static 
set policy-options policy-statement static2-to-ospf term 1 then accept 

set routing-options rib inet6.0 static route 3030::1/128 next-hop 9009:4::2 
set routing-options rib inet6.0 static route 4040::1/128 next-hop 9009:4::2 


Device 3 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:4::2/64 
set interfaces loO unit O family inet address 3.3.3.3/32 

set interfaces loO unit 0 family inet6 address 3030::1/128 

set interfaces loO unit O family inet6 address 4040::1/128 

set routing-options rib inet6.0 static route ::/0 next-hop 9009:4::1 


Device 4 


set interfaces fe-1/2/0 unit O family inet6 address 9009:1::2/64 
set interfaces fe-1/2/1 unit 0 family inet6 address 9009:6::1/64 
set interfaces fe-1/2/2 unit 0 family inet6 address 9009:3::1/64 
set interfaces loO unit O family inet address 4.4.4.4/32 

set protocols ospf3 export static-to-ospf 

set protocols ospf3 no-nssa-abr 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 
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set protocols ospf3 area 0.0.0.1 nssa default-Isa default-metric 10 

set protocols ospf3 area 0.0.0.1 nssa default-Isa metric-type 1 

set protocols ospf3 area 0.0.0.1 nssa default-Isa type-7 

set protocols ospf3 area 0.0.0.1 nssa no-summaries 

set protocols ospf3 area 0.0.0.1 interface fe-1/2/1.0 

set policy-options policy-statement static-to-ospf term 1 from protocol static 
set policy-options policy-statement static-to-ospf term 1 then accept 

set routing-options rib inet6.0 static route 1010::1/128 next-hop 9009:1::1 
set routing-options rib inet6.0 static route 2020::1/128 next-hop 9009:1::1 


Device 5 


set interfaces fe-1/2/0 unit O family inet6 address 9009:1::1/64 
set interfaces loO unit O family inet address 5.5.5.5/32 

set interfaces loO unit 0 family inet6 address 1010::1/128 

set interfaces loO unit O family inet6 address 2020::1/128 

set routing-options rib inet6.0 static route ::/0 next-hop 9009:1::2 


Device 6 


set interfaces fe-1/2/0 unit 0 family inet6 address 9009:3::2/64 
set interfaces loO unit O family inet address 6.6.6.6/32 

set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf3 area 0.0.0.0 interface |o0.0 passive 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see “Using the CLI Editor in Configuration Mode” in the CLI User Guide. 


To configure Device 4: 


1. Configure the interfaces. 


[edit interfaces] 
user@4# set fe-1/2/0 unit O family inet6 address 9009:1::2/64 
user@4# set fe-1/2/1 unit 0 family inet6 address 9009:6::1/64 


user@4# set fe-1/2/2 unit 0 family inet6 address 9009:3::1/64 
user@4# set loO unit O family inet address 4.4.4.4/32 


. Enable OSPFv3 on the interfaces that are in area O. 


[edit protocols ospf3 area 0.0.0.0] 
user@4# set interface fe-1/2/2.0 
user@4# set interface lo0.0 passive 


. Enable OSPFv3 on the interface that is in area 1. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set interface fe-1/2/1.0 


. Configure an OSPFv3 NSSA. 


The nssa statement is required on all routing devices in the area. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set nssa 


. On the ABR, inject a default route into the area. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set nssa default-Isa default-metric 10 


. (Optional) On the ABR, specify the external metric type for the default route. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set nssa default-Isa metric-type 1 


. (Optional) On the ABR, specify the flooding of Type 7 LSAs. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set nssa default-Isa type-7 


. On the ABR, restrict summary LSAs from entering the area. 
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[edit protocols ospf3 area 0.0.0.1] 
user@4# set nssa no-summaries 


9. Disable exporting Type 7 LSAs into the NSSA. 


This setting is useful if you have an AS boundary router that is also an ABR with an NSSA area attached. 


[edit protocols ospf3] 
user@4# set no-nssa-abr 


10. Configure static routes to the customer network. 


[edit routing-options rib inet6.0 static] 
user@4# set route 1010::1/128 next-hop 9009:1::1 
user@4# set route 2020::1/128 next-hop 9009:1::1 


11. Configure a policy to inject the static routes into OSPFv3. 


[edit policy-options policy-statement static-to-ospf term 1] 
user@4# set from protocol static 
user@4# set then accept 


12. Apply the policy to OSPFv3. 


[edit protocols ospf3] 
user@4# set export static-to-ospf 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


Device 4 


user@4# show interfaces 
fe-1/2/0 { 
unit O { 
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family ineté { 
address 9009:1::2/64; 


} 
unit O { 
family ineté { 
address 9009:6::1/64; 


} 
unit O { 
family ineté { 
address 9009:3::1/64; 


} 
lo0 { 
unit O { 
family inet { 
address 4.4.4.4/32; 


user@4# show protocols 
ospf3 { 
export static-to-ospf; 
no-nssa-abr; 
area 0.0.0.0 { 
interface fe-1/2/2.0; 
interface 100.0 { 
passive; 


} 
area 0.0.0.1 { 
nssa { 
default-lsa { 
default-metric 10; 
metric-type 1; 
type-7; 
} 


no-summaries; 
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} 
interface fe-1/2/1.0; 


user@4# show policy-options 
policy-statement static-to-ospf { 
term 1 { 
from protocol static; 
then accept; 


user@4# show routing-options 
rib inet6.0 { 
static { 
route 1010::1/128 next-hop 9009:1::1; 
route 2020::1/128 next-hop 9009:1::1; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ Verifying the Routes in the OSPFv3 Stub Area | 155 
@ Verifying the Type of LSAs | 158 


Confirm that the configuration is working properly. 
Verifying the Routes in the OSPFv3 Stub Area 


Purpose 


Make sure that the expected routes are present in the routing tables. 


Action 
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From operational mode on Device 1 and Device 6, enter the show route command. 


user@1> show route 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


i,t, l/ 32 2 | Daeecir/ Oi] Oss25eu 


> wie lod. 0 


inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 

Bo /0 “(OSE S/I5O] Wles2¢58, metcieile iil, tag 
= wale #e-1/2/0.0 

310) 310) 8 8 Lf Wes} FAOSP Hey 85 0) mO 4 4410.27 aac tissu Oy mt acum) 
> wile te-1/2/1.0 

AOA SAL / W283} =(OSETS/150] W2StAsO2, merciese WO, ice 0 
2 Wile 2-1/2 /1..0 

HOOVeSe3 ee = (Daeseir/O] Ose25e 34 


S wale t=) 2/10 
OSE S/O] OS325e24, weitere i 
S wie #e=1/ 2/10 


MOSehs si /i12s = || LOGS IL/O]| Ose 252 34 
Local via fe-1/2/1.0 
9009:6::/64 * (Direct / 0] OSs2aes4 


> wie #e—1/2/0 0 
OSE RS OOS s25i1S4 eee itera ome 
S wale, t= 1/2/00 


QOOIVsos 32/126 ‘a hoeall/ OO sia25: 34 
Local via fe-1/2/0.0 
fe80::/64 * (Disc /M] O8s25e sa 


hvala) ee / 2/0) a0 
DissecieOlmOSeaoo4 

2 Wile we-1/2/1.0 
fe80::2a0:a514:0:44c/128 

Jahoecll/OimOsia25n 04 

Local via fe-1/2/0.0 

fe80::2a0:a514:0:74c/128 

‘a pho@aulysO)mO sib 134 
Local wae te—1/2/ i. 0 











rE OZR 25/128 


J OSPES/AuO OSE /ea0.0}, 
MultiRecv 


user@6> show route 


meters iL 


inet.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, 


906 5656/ 32 


= (Dalieeeic /@]] OS2268 57 


> wie lol), 0 


Last Active, * = Both 


Ineo. 0 Liv destamataons), 2 ~soutres: (li active, 10) holddown,, 0) hadden)) 








+ = Active Route, 

















IDLO s gi/ 12s “(OSS S/150] OSs ies 59), 
Pav ie e200 
ZO2Z08 gil /f1l2e “(OS273/150] Oseilos 5%, 
2S Wile we-1/2/0.0 
BOSO08 31/128 * [OSPF3/150] 02:44:34, 
2 Wile we-1/2/0.0 
4040::1/128 *[OSPE3/ 150) 02:44 347, 
2 Wile wS—1/2/ 0.0 
HOOVS 3 s3 et = (Dalescie/ 0] Ose 26229) 
S Wila #6-1/2/0.0 
OSEr Sy AhONMmOSE iGo) 
S Wile te-1/2/0.0 
MOONE Se sB/LAy ~ocal/ Ol] OSs26329 
Local via fe-1/2/0. 
MOIR S39 / G4 *[OSPF3/10] 02:44:34, 
Seavey) 27/010 
MOGs 3/64 ~(OS273/10] OS31Ge59, 
2 Wie 2S 1/2/ 0.0 
£e80::/64 * (Direct / Ol 03226: 29 
2 Wile we-—1/2/0.0 
fe80::2a0:a514:0:64c/128 
* |Locall/ 0) 03326729 
Local via fe-1/2/0. 
O28 3 H/ 12s PAOSE RS a Oh eOs ceeaiae owe, 


Meaning 


MultiRecv 


Last Active, * = Both 


metric 0, tag 0 


meceie 0, tag © 


metric 0, tag 0 


metric 0, tag 0 


Mmetersieem 


0 


macweiLe §} 


mEeIe 2 


Me piace 
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On Device 1, the default route (::/0) has been learned because of the default-metric statement on the 
ABR, Device 4. The customer routes 3030::1 and 4040::1 have been learned from Device 2. The 1010::1 
and 2020::1 routes have been suppressed. They are not needed because the default route can be used 
instead. 


On Device 6 in area O, all of the customer routes have been learned. 
Verifying the Type of LSAs 


Purpose 


Verify the type of LSAs that are in the area. 


Action 


From operational mode on Device 1, enter the show ospf3 database nssa detail command. 


user@4> show ospf3 database nssa detail 


meee. OO 0.1 
Type ID Adv Rtr Seq Age Cksum Len 
NSSA ORO Oren Bane oo 0x80000004 2063 Oxceaf 60 
Pies, SISOS ol fee 
Prefix-options 0x8, Metric 0, Type 2, 
BawiGluncicl Cliaae OOO isoatecr 2, 
NSSA OROROR; Be B ot oe 0x80000004 1463 O0x3627 60 
Prefix 4040::1/128 
Prefix-options 0x8, Metric 0, Type 2, 
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Prefix-options 0x0, Metric 10, Type 1, 


Meaning 


Device 4 is not sending Type 7 (NSSA) LSAs for customer routes 1010::1/128 and 2020::1/128. If you 
were to delete or deactivate the no-nssa-abr statement and then rerun the show ospf3 database nssa 
detail command, you would see that Device 4 is sending Type 7 LSAs for 1010::1/128 and 2020::1/128. 


Understanding OSPF Virtual Links for Noncontiguous Areas 


OSPF requires that all areas in an autonomous system (AS) must be physically connected to the backbone 
area (area 0). In large networks with many areas, in which direct connectivity between all areas and the 

backbone area is physically difficult or impossible, you can configure virtual links to connect noncontiguous 
areas. Virtual links use a transit area that contains two or more area border routers (ABRs) to pass network 


159 


traffic from one adjacent area to another. The transit area must have full routing information and it cannot 
be a stub area. For example, Figure 15 on page 159 shows a virtual link between a noncontiguous area and 
the backbone area through an area connected to both. 


Figure 15: OSPF Topology with a Virtual Link 
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In the topology shown in Figure 15 on page 159, a virtual link is established between area 0.0.0.3 and the 
backbone area through area 0.0.0.2. The virtual link transits area 0.0.0.2. All outbound traffic destined for 
other areas is routed through area 0.0.0.2 to the backbone area and then to the appropriate ABR. All 
inbound traffic destined for area 0.0.0.3 is routed to the backbone area and then through area 0.0.0.2. 


Example: Configuring OSPF Virtual Links to Connect Noncontiguous Areas 


IN THIS SECTION 


Requirements | 159 
Overview | 160 
Configuration | 160 


Verification | 163 


This example shows how to configure an OSPF virtual link to connect noncontiguous areas. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 
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e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


If any routing device on the backbone is not physically connected to the backbone, you must establish a 
virtual connection between that routing device and the backbone to connect the noncontiguous areas. 


To configure an OSPF virtual link through an area, you specify the router ID (IP address) of the routing 
devices at each end of the virtual link. These routing devices must be area border routers (ABRs), with one 
that is physically connected to the backbone. You cannot configure virtual links through stub areas. You 
must also specify the number of the area through which the virtual link transits (also known as the transit 
area). You apply these settings to the backbone area (defined by the area 0.0.0.0) configuration on the 
ABRs that are part of the virtual link. 


In this example, Device R1 and Device R2 are the routing devices at each end of the virtual link, with 
Device R1 physically connected to the backbone, as shown in Figure 16 on page 160. You configure the 
following virtual link settings: 


e neighbor-id—Specifies the IP address of the routing device at the other end of the virtual link. In this 
example, Device R1 has a router ID of 192.0.2.5, and Device R2 has a router ID of 192.0.2.3. 


e transit-area—Specifies the area identifier through which the virtual link transits. In this example, area 
0.0.0.3 is not connected to the backbone, so you configure a virtual link session between area 0.0.0.3 
and the backbone area through area 0.0.0.2. Area 0.0.0.2 is the transit area. 


Figure 16: OSPF Virtual Link 
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Configuration 


CLI Quick Configuration 
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e To quickly configure an OSPF virtual link on the local routing device (Device R1), copy the following 
commands and paste them into the CLI. 


NOTE: You must configure both routing devices that are part of the virtual link and specify 
the applicable neighbor ID on each routing device. 


[edit] 
set routing-options router-id 192.0.2.5 
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.0.2.3 transit-area 0.0.0.2 


e To quickly configure an OSPF virtual link on the remote routing device (Device R2), copy the following 
commands and paste them into the CLI. 


[edit] 
set routing-options router-id 192.0.2.3 
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 192.0.2.5 transit-area 0.0.0.2 


Step-by-Step Procedure 


To configure an OSPF virtual link on the local routing device (Device R1): 


1. Configure the router ID. 


[edit] 
user@R1# set routing-options router-id 192.0.2.5 


2. Enter OSPF configuration mode and specify OSPF area 0.0.0.0. 


NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@R1# edit protocols ospf area 0.0.0.0 


3. Configure an OSPF virtual link and specify the transit area 0.0.0.2. 
This routing device must be an ABR that is physically connected to the backbone. 
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[edit protocols ospf area 0.0.0.0] 
user@R1# set virtual-link neighbor-id 192.0.2.3 transit-area 0.0.0.2 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0] 
user@R1# commit 


Step-by-Step Procedure 


To configure an OSPF virtual link on the remote ABR (Device R2, the routing device at the other end of 
the link): 


1. Configure the router ID. 


[edit] 
user@R2# set routing-options router-id 192.0.2.3 


2. Enter OSPF configuration mode and specify OSPF area 0.0.0.0. 


NOTE: For an OSPFv3 virtual link, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@R2# edit protocols ospf area 0.0.0.0 


3. Configure an OSPF virtual link on the remote ABR and specify the transit area 0.0.0.2. 
This routing device is not physically connected to the backbone. 


[edit protocols ospf area 0.0.0.0] 
user@R2# set virtual-link neighbor-id 192.0.2.5 transit-area 0.0.0.2 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0] 
user@R2# commit 
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Results 


Confirm your configuration by entering the show routing-options and the show protocols ospf commands. 
If the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


Configuration on the local routing device (Device R1): 


user@R1#: show routing-options 
router-id 192.0.2.5; 


user@R1# show protocols ospf 
area 0.0.0.0 { 
virtual-link neighbor-id 192.0.2.3 transit-area 0.0.0.2; 


Configuration on the remote ABR (Device R2): 


user@R2#: show routing-options 
router-id 192.0.2.3; 


user@R2# show protocols ospf 
area 0.0.0.0 { 
virtual-link neighbor-id 192.0.2.5 transit-area 0.0.0.2; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 


@ Verifying Entries in the Link-State Database | 163 
@ Verifying OSPF Interface Status and Configuration | 164 


Confirm that the configuration is working properly. 


Verifying Entries in the Link-State Database 


Purpose 


Verify that the entries in the OSPFv2 or OSPFv3 link-state database display. The Router field in the OSPFv2 
output displays LSA information, including the type of link. If configured as a virtual link, the Type is Virtual. 
For each router link, the Type field in the OSPFv3 output displays the type of interface. If configured as 
a virtual link, the Type is Virtual. 


Action 
From operational mode, enter the show ospf database detail command for OSPFv2, and enter the show 
ospf3 database detail command for OSPFv3. 


Verifying OSPF Interface Status and Configuration 


Purpose 
Verify that the OSPFv2 or OSPFv3 interface is configured and status displays. The Type field displays the 
type of interface. If the interface is configured as part of a virtual link, the Type is Virtual. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Example: Configuring OSPFv3 Virtual Links 


IN THIS SECTION 


Requirements | 164 
Overview | 165 
Configuration | 165 


Verification | 179 


This example shows how to configure OSPF version 3 (OSPFv3) with some areas that do not have a direct 
adjacency to the backbone area (area 0). When an area lacks an adjacency with area O, a virtual link is 
required to connect to the backbone through a non-backbone area. The area through which you configure 
the virtual link, known as a transit area, must have full routing information. The transit area cannot be a 
stub area. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 
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Overview 


Figure 17 on page 165 shows the topology used in this example. 


Figure 17: OSPFv3 with Virtual Links 
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Device 0, Device 1, Device 2, and Device 3 are connected to the OSPFv3 backbone Area 0. Device 2, 
Device 3, and Device 4 connect to each other across Area 1. and Area 2 is located between Device 4 and 
Device 5. Because Device 5 does not have a direct adjacency to Area 0, a virtual link is required across 
Area 1 between Device 3 and Device 4. Similarly, because Device O and Device 1 have two separate Area O 


backbone sections, you need to configure a second virtual link across Area 1 between Device 2 and 
Device 3. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device 0 


set logical-systems 0 interfaces so-0/3/2 unit 0 family inet6 address 9009:1::1/64 
set logical-systems 0 interfaces loO unit 0 family inet address 192.168.0.1/32 
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set logical-systems 0 interfaces loO unit O family inet6 address feee::10:255:71:4/128 
set logical-systems 0 protocols ospf3 area 0.0.0.0 interface so-0/3/2.0 

set logical-systems 0 protocols ospf3 area 0.0.0.0 interface lo0.0 passive 

set logical-systems 0 routing-options router-id 192.168.0.1 


Device 1 


set logical-systems 1 interfaces at-2/0/0 atm-options vpi 0 

set logical-systems 1 interfaces at-2/0/0 unit 0 family inet6 address 9009:2::1/64 
set logical-systems 1 interfaces at-2/0/0 unit 0 vci 0.77 

set logical-systems 1 interfaces loO unit 0 family inet address 192.168.1.1/32 

set logical-systems 1 interfaces loO unit O family inet6 address feee::10:255:71:1/128 
set logical-systems 1 protocols ospf3 area 0.0.0.0 interface at-2/0/0.0 

set logical-systems 1 protocols ospf3 area 0.0.0.0 interface lo0.0 passive 

set logical-systems 1 routing-options router-id 192.168.1.1 


Device 2 


set logical-systems 2 interfaces so-0/2/0 unit 0 family inet6 address 9009:3::1/64 

set logical-systems 2 interfaces fe-1/1/0 unit 0 family inet6 address 9009:4::1/64 

set logical-systems 2 interfaces at-0/3/1 atm-options vpi 0 maximum-vcs 1200 

set logical-systems 2 interfaces at-0/3/1 unit 0 family inet6 address 9009:2::2/64 

set logical-systems 2 interfaces at-0/3/1 unit 0 vci 0.77 

set logical-systems 2 interfaces loO unit O family inet address 192.168.2.1/32 

set logical-systems 2 interfaces loO unit 0 family inet6 address feee::10:255:71:11/128 

set logical-systems 2 protocols ospf3 area 0.0.0.0 virtual-link neighbor-id 192.168.3.1 transit-area 
0.0.0.1 

set logical-systems 2 protocols ospf3 area 0.0.0.0 interface at-0/3/1.0 

set logical-systems 2 protocols ospf3 area 0.0.0.1 interface fe-1/1/0.0 

set logical-systems 2 protocols ospf3 area 0.0.0.1 interface so-0/2/0.0 

set logical-systems 2 protocols ospf3 area 0.0.0.1 interface lo0.0 passive 

set logical-systems 2 routing-options router-id 192.168.2.1 


Device 3 
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set logical-systems 3 interfaces so-0/3/2 unit 0 family inet6 address 9009:1::2/64 

set logical-systems 3 interfaces t1-0/2/1 unit O family inet6 address 9009:5::1/64 

set logical-systems 3 interfaces so-0/3/0 unit 0 family inet6 address 9009:3::2/64 

set logical-systems 3 interfaces loO unit O family inet address 192.168.3.1/32 

set logical-systems 3 interfaces loO unit O family inet6 address feee::10:255:71:3/128 

set logical-systems 3 protocols ospf3 area 0.0.0.1 interface so-0/3/0.0 

set logical-systems 3 protocols ospf3 area 0.0.0.1 interface t1-0/2/1.0 

set logical-systems 3 protocols ospf3 area 0.0.0.1 interface lo0.0 passive 

set logical-systems 3 protocols ospf3 area 0.0.0.0 virtual-link neighbor-id 192.168.2.1 transit-area 
0.0.0.1 

set logical-systems 3 protocols ospf3 area 0.0.0.0 virtual-link neighbor-id 192.168.4.1 transit-area 
0.0.0.1 

set logical-systems 3 protocols ospf3 area 0.0.0.0 interface so-0/3/2.0 

set logical-systems 3 routing-options router-id 192.168.3.1 


Device 4 


set logical-systems 4 interfaces t1-0/2/1 unit O family inet6 address 9009:5::2/64 

set logical-systems 4 interfaces fe-0/0/0 unit O family inet6 address 9009:6::1/64 

set logical-systems 4 interfaces fe-1/1/0 unit 0 family inet6 address 9009:4::2/64 

set logical-systems 4 interfaces loO unit O family inet address 192.168.4.1/32 

set logical-systems 4 interfaces loO unit O family inet6 address feee::10:255:71:5/128 

set logical-systems 4 protocols ospf3 area 0.0.0.1 interface fe-1/1/0.0 

set logical-systems 4 protocols ospf3 area 0.0.0.1 interface t1-0/2/1.0 

set logical-systems 4 protocols ospf3 area 0.0.0.1 interface lo0.0 passive 

set logical-systems 4 protocols ospf3 area 0.0.0.2 interface fe-0/0/0.0 

set logical-systems 4 protocols ospf3 area 0.0.0.0 virtual-link neighbor-id 192.168.3.1 transit-area 
0.0.0.1 

set logical-systems 4 routing-options router-id 192.168.4.1 


Device 5 


set logical-systems 5 interfaces fe-0/0/0 unit O family inet6 address 9009:6::2/64 
set logical-systems 5 interfaces loO unit O family inet address 192.168.5.1/32 

set logical-systems 5 interfaces loO unit O family inet6 address feee::10:255:71:6/128 
set logical-systems 5 protocols ospf3 area 0.0.0.2 interface fe-0/0/0.0 

set logical-systems 5 protocols ospf3 area 0.0.0.2 interface lo0.0 passive 


set logical-systems 5 routing-options router-id 192.168.5.1 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 0: 


1. Configure the interfaces. 


[edit interfaces] 

user@O# set so-0/3/2 unit 0 family inet6 address 9009:1::1/64 
user@O# set loO unit O family inet address 192.168.0.1/32 
user@O# set loO unit O family inet6 address feee::10:255:71:4/128 


2. Add the interfaces into Area O of the OSPFv3 process. 


[edit protocols ospf3 area 0.0.0.0] 
user@O# set interface so-0/3/2.0 
user@O# set interface lo0.0 passive 


3. Configure the router ID. 


[edit routing-options] 
user@O# set router-id 192.168.0.1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 1: 


1. Configure the interfaces. 


[edit interfaces] 

user@1# set at-2/0/0 atm-options vpi 0 

user@1# set at-2/0/0 unit O family inet6 address 9009:2::1/64 
user@1# set at-2/0/0 unit O vci 0.77 
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user@1# set loO unit O family inet address 192.168.1.1/32 
user@1# set loO unit O family inet6 address feee::10:255:71:1/128 


2. Add the interfaces into Area O of the OSPFv3 process. 


[edit protocols ospf3 area 0.0.0.0] 
user@1# set interface at-2/0/0.0 
user@1# set interface lo0.0 passive 


3. Configure the router ID. 


[edit routing-options] 
user@1# set router-id 192.168.1.1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 2: 


1. Configure the interfaces. 


[edit interfaces] 

user@2# set so-0/2/0 unit 0 family inet6 address 9009:3::1/64 
user@2# set fe-1/1/0 unit 0 family inet6 address 9009:4::1/64 
user@2# set at-0/3/1 atm-options vpi 0 maximum-vcs 1200 
user@2# set at-0/3/1 unit O family inet6 address 9009:2::2/64 
user@2# set at-0/3/1 unit 0 vci 0.77 

user@2# set loO unit O family inet address 192.168.2.1/32 

user@2# set loO unit O family inet6 address feee::10:255:71:11/128 


2. Add the interfaces connected to Device 1, Device 3, and Device 4 into the OSPFv3 process. 


[edit protocols ospf3 area 0.0.0.0] 
user@2# set interface at-0/3/1.0 
[edit protocols ospf3 area 0.0.0.1] 
user@2# set interface fe-1/1/0.0 
user@2# set interface so-0/2/0.0 
user@2# set interface lo0.0 passive 
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3. Configure the virtual link to Device 3 through Area 1 so that Device 1 can access the discontiguous 
portion of the OSPF backbone found on Device O. 


[edit protocols ospf3 area 0.0.0.0] 
user@2# set virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1 


4. Configure the router ID. 


[edit routing-options] 
user@2# set router-id 192.168.2.1 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 3: 


1. Configure the interfaces. 


[edit interfaces] 

user@3# set so-0/3/2 unit 0 family inet6 address 9009:1::2/64 
user@3# set t1-0/2/1 unit O family inet6 address 9009:5::1/64 
user@3# set so-0/3/0 unit 0 family inet6 address 9009:3::2/64 
user@3# set loO unit 0 family inet address 192.168.3.1/32 
user@3# set loO unit O family inet6 address feee::10:255:71:3/128 


2. For the OSPFv3 process on Device 3, configure the interfaces connected to Device 2 and Device 4 
into Area 1 and the interface connected to Device 0 into Area 0. 


[edit protocols ospf3 area 0.0.0.1] 
user@3# set interface so-0/3/0.0 
user@3# set interface t1-0/2/1.0 
user@3# set interface lo0.0 passive 
[edit protocols ospf3 area 0.0.0.0] 
user@3# set interface so-0/3/2.0 


3. Configure two virtual links through Area 1—one connecting to Device 2 and the second connecting to 
Device 4. 


The virtual links allow Device 5 to access the OSPF backbone, and connect the discontiguous sections 
of Area O located at Device 0 and Device 1. 
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[edit protocols ospf3 area 0.0.0.0] 
user@3# set virtual-link neighbor-id 192.168.2.1 transit-area 0.0.0.1 
user@3# set virtual-link neighbor-id 192.168.4.1 transit-area 0.0.0.1 


4. Configure the router ID. 


[edit routing-options] 
user@3# set router-id 192.168.3.1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 4: 


1. Configure the interfaces. 


[edit interfaces] 

user@4# set t1-0/2/1 unit O family inet6é address 9009:5::2/64 
user@4# set fe-0/0/0 unit 0 family inet6 address 9009:6::1/64 
user@4# set fe-1/1/0 unit 0 family inet6 address 9009:4::2/64 
user@4# set loO unit O family inet address 192.168.4.1/32 
user@4# set loO unit O family inet6 address feee::10:255:71:5/128 


2. On Device 4, add the connected interfaces into the OSPFv3 process. 


[edit protocols ospf3 area 0.0.0.1] 
user@4# set interface fe-1/1/0.0 
user@4# set interface t1-0/2/1.0 
user@4# set interface lo0.0 passive 
[edit protocols ospf3 area 0.0.0.2] 
user@4# set interface fe-0/0/0.0 


3. Configure the virtual link to Device 3 through Area 1 so that Device 5 can access the OSPF backbone. 


[edit protocols ospf3 area 0.0.0.0] 
user@4# set virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1 


4. Configure the router ID. 
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[edit routing-options] 
user@4# set router-id 192.168.4.1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device 5: 


1. Configure the interfaces. 


[edit interfaces] 

user@5# set fe-0/0/0 unit 0 family inet6 address 9009:6::2/64 
user@5# set loO unit O family inet address 192.168.5.1/32 
user@5# set loO unit O family inet6 address feee::10:255:71:6/128 


2. Add the interfaces into the OSPFv3 process. 


[edit protocols ospf3 area 0.0.0.2] 
user@5# set interface fe-0/0/0.0 
user@5# set interface lo0.0 passive 


3. Configure the router ID. 


[edit routing-options] 
user@5# set router-id 192.168.5.1 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
and show routing-options commands. If the output does not display the intended configuration, repeat 
the instructions in this example to correct the configuration. 


Device 0 


user@0# show interfaces 
so-0/3/2 { 
unit O { 
family ineté { 


address 9009:1::1/64; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.0.1/32; 
} 
family ineté { 
address feee::10:255:71:4/128; 


} 
user@0# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface so-0/3/2.0; 
interface 100.0 { 
passive; 


} 


user@0O# show routing-options 
router-id 192.168.0.1; 


Device 1 


user@1# show interfaces 
at-2/0/0 { 
atm-options { 
vpi O; 
} 
unit O { 
family ineté { 
address 9009:2::1/64; 


loO { 
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unit O { 
family inet { 
address 192.168.1.1/32; 
} 
family ineté { 
address feee::10:255:71:1/128; 


} 
user@1# show protocols 
ospf3 { 
area 0.0.0.0 { 
interface at-2/0/0.0; 
interface 100.0 { 


passive; 


} 


user@1# show routing-options 
router-id 192.168.1.1; 


Device 2 


user@2# show interfaces 
so-0/2/0 { 
unit O { 
family ineté { 
address 9009:3::1/64; 


} 
fe-1/1/0 { 
unit O { 
family ineté { 
address 9009:4::1/64; 


} 
at-0/3/1 { 
atm-options { 
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vpi O { 
maximum-vcs 1200; 


} 
unit O { 
vci 0.77; 
family ineté { 
address 9009:2::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.2.1/32; 
} 
family ineté { 
address feee::10:255:71:11/128; 


} 
user@2# show protocols 
ospf3 { 
area 0.0.0.0 { 
virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1; 
interface at-0/3/1.0; 
} 
area 0.0.0.1 { 
interface fe-1/1/0.0; 
interface so-0/2/0.0; 
interface 100.0 { 
passive; 


} 


user@2# show routing-options 
router-id 192.168.2.1; 


Device 3 
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user@3# show interfaces 
so-0/3/2 { 
unit O { 
family ineté { 
address 9009:1::2/64; 


} 
t1-0/2/1 { 
unit O { 
family ineté { 
address 9009:5::1/64; 


} 
so-0/3/0 { 
unit O { 
family ineté { 
address 9009:3::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.3.1/32; 
} 
family ineté { 
address feee::10:255:71:3/128; 


} 
user@3# show protocols 
ospf3 { 
area 0.0.0.1 { 
interface so-0/3/0.0; 
interface t1-0/2/1.0; 
interface 100.0 { 


passive; 


} 
area 0.0.0.0 { 
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virtual-link neighbor-id 192.168.2.1 transit-area 0.0.0.1; 
virtual-link neighbor-id 192.168.4.1 transit-area 0.0.0.1; 
interface so-0/3/2.0; 


} 


user@3# show routing-options 
router-id 192.168.3.1; 


Device 4 


user@4# show interfaces 
t1-0/2/1 { 
unit O { 
family ineté { 
address 9009:5::2/64; 


} 
fe-0/0/0 { 
unit O { 
family ineté { 
address 9009:6::1/64; 


} 
fe-1/1/0 { 
unit O { 
family ineté { 
address 9009:4::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.4.1/32; 
} 
family ineté { 
address feee::10:255:71:5/128; 
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} 
user@4# show protocols 
ospf3 { 
area 0.0.0.1 { 
interface fe-1/1/0.0; 
interface t1-0/2/1.0; 
interface 100.0 { 


passive; 


} 
area 0.0.0.2 { 
interface fe-0/0/0.0; 
} 
area 0.0.0.0 { 
virtual-link neighbor-id 192.168.3.1 transit-area 0.0.0.1; 


} 
user@4# show routing-options 
router-id 192.168.4.1; 


Device 5 


user@5# show interfaces 
fe-0/0/0 { 
unit O { 
family ineté { 
address 9009:6::2/64; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.5.1/32; 
} 
family ineté { 
address feee::10:255:71:6/128; 
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} 
user@5# show protocols 
ospf3 { 
area 0.0.0.2 { 
interface fe-0/0/0.0; 
interface 100.0 { 
passive; 


} 
user@5# show routing-options 
router-id 192.168.5.1; 


If you are done configuring the devices, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Device O Status | 180 
Device 1 Status | 182 
Device 2 Status | 185 


e 
o) 
® 
@ Device 3 Status | 188 
@ Device 4 Status | 192 
is) 


Device 5 Status | 196 


Confirm that the configuration is working properly. 
To verify proper operation of OSPF v3 for IPv6, use the following commands: 


e show ospf3 interface 


show ospf3 neighbor 


show ospf3 database 


show ospf3 route 


e show interfaces terse (to see the IPvé link local address assigned to the loO interface) 


Device 0 Status 


NOTE: To view prefix information, you must use the extensive option with the show ospf3 
database command. 


Purpose 


Verify that Device 0 has learned the expected routes and has established the expected neighbor adjacencies. 


In the show ospf3 database sample output, the stars indicate the “best” routes. These routes are the routes 
that are installed in the routing table. 


Action 


user@0> show ospf3 database 


Area 0.0.0.0 


Type 
Router 


Router 


Router 


Router 


Router 


aigy 
in 
In 
In 
in 
ag 
In 
In 
in 
In 
In 
In 
ay 
iy 
an 
In 
ale) 
aigy 
in 
ame) 


terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 


terArPf 





terArPf 
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fey © ~S) oy, or Ye: fer 2) 1 ~~] Yer fear ie) “or jor @ ff) ver or 2 a oS Sr fa >) 


eS oo SS S&S ec ewe eS @&@ S&S Se ec Sc S&S oS oS oS eS SES oe oS Oo SF ES Ss 


oe So ec 2 2 S&S oS So ec 2 2 |] S&S S&S oc oe f& & ofS Sc eG So Sf] S&S 
Wey fee) Sa) ep) nS (Ice, tS Se eS IS IS SS Se eS Sc 


Adv 


1hO2F 
127 
1hgI2F 
LZ « 
LE 
LOZ « 
WA 
LO 
1927 
LZ 
LZ « 
LY 
lho27 
IZ 
12 
LZ « 
LY 
LZ « 
O27 
InoI27: 
INO2 
LE 
LZ « 
LO 
1A 5 


RUE Te 


LIS. 
GIS. 
168. 
168. 
LORS) 6 
168. 
ALIS 
168. 
LOIS. 
LOIS) 
168. 
168. 
LOIS 
ALIS) 5 
LOIS 
168. 
LOIS) « 
168. 
ALOIS 
168. 
AGIs 5 
LHS) « 
168. 
LOS 
168. 





(oy (G8) esr IGS) Gs) ee) SS) Sy feo eS) (BS) IS) ES GS) eS) I 


Ss Ss 


Ss 





Seq 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 


0x8 
0x8 
0x8 


000 
000 
000 


0x8000 


0x8 


000 


0x8000 


0x8 
0x8 
0x8 


000 
000 
000 





0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 








Age 
1858 
1861 
1918 
2104 
AQULe 

2311 

43 
LY SL 
2668 
2856 
2481 

417 
2854 
LL YZY) 
2667 

DAS) 
DBP 

7194 

606 

419 
L25) 
2669 

981 
2481 
224 


Cksum 

Ox6e21 
Osos 
Ox9e62 
Ox46d 

0x7016 
ORS SIC 
0x156 

Ox31a4 
Osco Splsts 
Oxfa59 
Oxe3fb 
Oxf£562 
0x84d 

Oxbc26 
Ox2ca9 
Oxe56e 
OxdeOl 
Oxf461 
Oxf85b 
Oxfe54 
0xd906 
Oxfleb 
Oxbc95 
Ox8f£4f£ 
Oxf0dd 


Len 
40 
40 
56 
72 
40 
36 
Sis 
44 
44 
36 
44 
36 
36 
44 
44 
36 
44 
36 
36 
36 
44 
44 
36 
44 
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onesie (0,0 ,0, Le 192 M6824 61 0x8000008f 

Tinie clare Pitexqus Or On Ones LA LE 60 ot 0x80000094 

InerahcPrx O20. 051 192, 1681. il 0x80000095 

impmaanem O.0.0.1 192. 163.2 oi 0x80000096 

iiereevMeeer, (50) 410, 1 192 168.561 0x80000097 

interface so-0/3/2.0 Area 0.0.0.0 

Type ID Adv Rtr seq 

Link 050.052 LA. LG 60 ot 0x80000091 

Link OR Oe Orr) LOA. LG, Si il 0x80000091 

user@0> show ospf3 interface 

Interface State Area DIR IO) 

100.0 DRother 0.0.0.0 ORO RIOR) 

BO-0/ 3/2 0 PErare  O.0.0.0 ORORORO) 

user@0> show ospf3 neighbor 

ID Interface State IDieaL De 

192,168.31 Som Oi syi2en0 Full 128 
Neighbor-address fe80::2a0:a514:0:24c 

user@0> show ospf3 route 

Prefix Path Route 

Type Type 

U2 4 WSS. Ibs Intra Router 
NH-interface so-0/3/2.0 

W926 WSS 5 25 I Intra Area BR 
NH-interface so-0/3/2.0 

U2 , 168.351 Intra Area BR 
NH-interface so-0/3/2.0 

U2 W684 50 Intra Area BR 
NH-interface so-0/3/2.0 

HOON 1s 6/4 Intra Network 
NH-interface so-0/3/2.0 

MOOV Ls 32/1as Intra Network 
NH-interface so-0/3/2.0 

NOOIR 2s 3/4 Intra Network 
NH-interface so-0/3/2.0 

MOON Bes B/ Lay Intra Network 
NH-interface so-0/3/2.0 

MOOIVR Ss 3/54 Inter Network 
NH-interface so-0/3/2.0 

9009:4::/64 Inter Network 
NH-interface so-0/3/2.0 

















2 SAL 
2858 
2861 

VIS 
1167 


Age 
858 
1354 


BD 
QO. 
QO. 


ad 
33 


OxacdSa 
Oxbf9Ff 
0x87d6 
Oxc7bd 
0x93£0 


Cksum 
OxcOc7 
Ox84£9 


oD 
OROR0 
ORLORIO 


44 
64 
64 
64 
64 


Len 
56 
56 


NH Metric 
Type 
ie 3 
iP Da 
TP i 
IP 2 
TP 1 
ie lf 
ie 3 
iP Z 
TP 2 
IP S 
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181 


182 






































9009:5::/64 Inter Network IP 2 
NH-interface so-0/3/2.0 

MOOMsSs 3/4 Inter Network IP 3 
NH-interface so-0/3/2.0 

MOIMRGe gl /128 Inter Network IP 2 
NH-interface so-0/3/2.0 

FEE SIME 255 eR Fil gil 128) Intra Network IP 3 
NH-interface so-0/3/2.0 

feee::10:255:71:3/128 Inter Network IP il 
NH-interface so-0/3/2.0 

feee::10:255:71:4/128 Intra Network IP 0 
NH-interface 100.0 

feee::10:255:71:5/128 Inter Network IP 2 
NH-interface so-0/3/2.0 

feee::10:255:71:6/128 Inter Network IP 8 
NH-interface so-0/3/2.0 

FSSOR SIME255Rg 7g 11/128 Inter Network 12 2 




















NH-interface so-0/3/2.0 





user@0> show interfaces terse 


Interface Admin Link Proto Local Remote 

Me=1/27/C 

so-0/3/2.0 up up inet6 QO Le gi /oaAl 
fe80::2a0:a514:0:14c/64 

100 

100.0 up up inet 192 1680.0 --> 0/0 


inet6 fe80::2a0:a50f:fc56:14c 
feee::10:255:71:4 


Device 1 Status 


Purpose 


Verify that Device 1 has learned the expected routes and has established the expected neighbor adjacencies. 


Action 


user@1> show ospf3 interface 


Interface State Area DR ID BDR ID Nbrs 
100.0 DRother 0.0.0.0 OR ORONO ORO MORO) 0 
eles 2/0/10 5 © Prrore @.0.0.0 O.0 5,050 CRO Orr0) i 


user@1> show ospf3 neighbor 


ID Lime SiereeS 
192168261 at-2/0/0.0 

Neighbor-address fe80::2a0:a514:0:c4c 
user@1> show ospf3 database 
meee 0.0.0.0 

Type ID Adv Rtr 
Router OPORTO) 192,168,061 
Router 0.0.0.0 192,168,151 
Router OROR ORO) 192, 168.261 
Router OROR ORS) 192,168.31 
Router OROR ORO) 192 TOS .4 41 
InterArPEx 0.0.0.1 LOE Asks 4 od 
limcegieaePin< 0.0 ,10,2 LZ UG 62d 
iimegueswePin< 010,053 LOA o LO Bed 
InterArPfx 0.0.0.4 LOZ 5 LG 5 Bod 
InterArPE—x 0.0.0.5 LOZ  LGS. 261 
InterArPEx 0.0.0.6 LOS GS od 
IimeGiAwieits 1050) 410, 1 LOZ  LGe. 361 
plemie cre Abra ste xa ON NORE Ol LOA LOo Sed 
limcereuePin<e 0.0 ,10.3 LOZ WO > Bod 
InterArPf£x 0.0.0.4 LOZ o Lo Bed 
InterArPEx 0.0.0.5 LOVE AG. Sod 
InterArPEx 0.0.0.6 LOZ LG. Sel 
InterArPEx 0.0.0.2 LOZ AOS oA 
limce@iwaePin< 0.0.0.3 WV 2y 5 Aish 5 ah 
InterArPf£x 0.0.0.4 V2 o LG oA. 
ence Avrastexqun Ol Onn Oyo AZ) 5 ALGich. ho 
InterArPEx 0.0.0.6 ALY) 5 AL GS) 5 Ah 
InterArPEx 0.0.0.7 HOV AGS) A. 
InterArPEx 0.0.0.8 IL) 5 ALS}, At 
lene cra Avra texan ORs One Olea 2h 5 LCS A a 
InterArPfx 0.0.0.10 V2 6 GI 5 A. 
imcwevasePine 0) 10 410.1 LOA LOSoOed 
TIMER eVATEP IES (0) 5 (0).410) 5 AL LOZ oAGsoil ed 
IME Reva O50 41051 U2 LG. 261 
ime wevAEP in 10). 0)4105 1 LOS oAGsko Sed 
interface at-2/0/0.0 Area 0.0.0.0 

Type ID Adv Rtr 
Link “0.0.0.2 192,168 , 1 
Link OFOR ORS: 192.1682 « 














user@1> show ospf3 route 








Phranis 


128 


seq 
Ox8000008F 
Ox8000008F 
0x80000090 
0x80000092 
Ox8000008F 
0x80000093 
0x80000093 
0x80000092 
0x80000090 
0x80000092 
0x80000090 
0x80000093 
0x80000094 
0x80000092 
0x80000090 
0x80000091 
Ox8000008F 
0x80000092 
0x80000092 
0x80000091 
0x80000090 
0x80000090 
0x80000091 
Ox8000008F 
0x80000090 
Ox8000008F 
0x80000095 
0x80000096 
0x80000096 
0x80000097 





seq 
0x80000091 
0x80000091 


Dead 
37 


Age 
2334 
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2486 

703 
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2203 
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253 

891 

328 
2203 
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703 
2766 
1268 
1080 

893 
2299) 

143 
1455 
2955 
2768 

705 

334 

een 
1265 
1641 


Age 
AZZ 
1453 


Cksum 

Ox6e21 
0x523d 
Ox9e62 
0x46d 

0x7016 
Ossie SIC 
0x156 

Ox31a4 
0xc320 
Oxf85a 
Oxe3fb 
Oxf562 
Ox64e 

Oxbc26 
Ox2aaa 
Oxe56e 
OxdeOl 
Oxf461 
Oxf85b 
Oxfe54 
0xd906 
Oxefec 
Oxbc95 
Ox8£4f 
Oxf0dd 
OxacdSa 
Oxbda0 
0x85d7 
Oxc7bd 
0x93£0 


Cksum 
Oxaecd 
Ox80f3 


Len 
40 
40 
56 
V2 
40 
36 
36 
44 
44 
36 
44 
36 
36 
44 
44 
36 
44 
36 
36 
36 
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Prefix 
1925 16S 5.051 

NH-interface at-2/0/0. 
U2 UGS 52 5 

NH-interface at-2/0/0. 
U2 ,lOSods4 

NH-interface at-2/0/0. 
WIV 9 AGS) 5 Abs aL 

NH-interface at-2/0/0. 
HOOS gi. 3 oe 

NH-interface at-2/0/0. 
VOOPs Le g2/128 

NH-interface at-2/0/0. 
SOO8e2e0/ 4 

NH-interface at-2/0/0. 
MOIR 28 32/128 

NH-interface at-2/0/0. 
MOV Se 3/64 

NH-interface at-2/0/0. 
9009:4::/64 

NH-interface at-2/0/0. 
9009:5::/64 

NH-interface at-2/0/0. 
9009:6::/64 

NH-interface at-2/0/0. 
MWOMsGs 1/128 

NH-interface at-2/0/0. 
FEEO8 SOs 255e Hig il/ 128 

NH-interface 100.0 
PSOSE CIOs soe Tis 3/128 

NH-interface at-2/0/0. 
feee::10:255:71:4/128 

NH-interface at-2/0/0. 
PSSSE CIOR A552 735/128 

NH-interface at-2/0/0. 
POSE S1OsZ5Se 71 36/i128 

NH-interface at-2/0/0. 
feee::10:255:71:11/128 

NH-interface at-2/0/0. 
user@1> show interfaces terse 
Interface 
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Admin Link Proto 
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Ian 


In 
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Ain 
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E1ee! 
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Ceres 
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Route 
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Metric 


Remote 


184 


185 


at-2/0/0.0 up up inet6 9009:2::1/64 
fe80::2a0:a514:0:b4c/64 
100 
100.0 up up inet 192,168.14 --> 0/0 
inet6 fe80::2a0:a50f:fc56:14c 
feee: 7102325537131 
Device 2 Status 
Purpose 


Verify that Device 2 has learned the expected routes and has established the expected neighbor adjacencies. 


Action 


user@2> show ospf3 interface 


Interface State Area DR ID BDR ID Nbrs 
aie—O/ 3/1 oC Pewee O.O.0.€ 0.0.0.0 0.0.0.0 1 
wi=19)2 168.3 ,i Beterc O0.0.0 ORO RO RO) CORIO RONG) 1 
100.0 DRother 0.0.0.1 CRO RIO RO CORIO RO 0 
50-0 / 2/0 56 Biewore O0.051 CORIO ORO ORO RORO 1 
fe-1/1/0.0 Bieter OO ,051 ORIORORO ORO RORO il 








user@2> show ospf3 neighbor 

















ID Interface State Piet Dead 

192, 168.1.1 aie) 3/1 5 0 Full IL 32 
Neighbor-address fe80::2a0:a514:0:b4c 

192 168 53 51, W192 168 55.51 Full 0 38 
Neighbor-address 9009:3::2 

192,168 5361 SO = 0/27 ORO iqwUL AL EAS) 38 
Neighbor-address fe80::2a0:a514:0:74c 

192,163.4.1 fe-1/1/0.0 iyouL AL 128 30 
Neighbor-address fe80::2a0:a514:0:a4c 








user@2> show ospf3 database 
Area 0.0.0.0 
Type ID Adv Rtr Seq Age Cksum Len 
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0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
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0x8000 
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0093 
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0090 
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0090 
0091 
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0091 
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0090 
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0092 
0094 
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0093 
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B52 
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iia 
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LSZNS) 
V6 
2640 
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LAOS) 
LBA 7 
SSO) 
2736 
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1515 
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Oxce 70 
Oxf85a 
Oxelfc 
Oxf£562 
Ox64e 

Oxbc26 
Ox2aaa 
Oxe56e 
Oxdc02 
Oxf461 
Oxf85b 
Oxfed54 
0xd906 
Oxefec 
Oxbc95 
0x8d50 
Oxeede 
OxacdSa 
Oxbda0 
0x85d7 
Oxc7bd 
0x93£0 


Cksum 

Ox8f£62 
0x39b7 
0x8768 
Oxec6c 
0x994d 
0xd839 
Oxd781 
Oxe002 
Oxc34e 
0x193b 
Oxed1 

Oxe824 
Ox6bf1 
Oxadb8 
O0x3c26 








Len 





186 


Uinta has curate O/ 5)/ ln OmArceau On Om On0) 


VS ID Adv Rtr 
Link O.0,0.52 Ws LO 
Link =O0 0058 AZ. LOS. 





inter kacs isO-0/ 2/00 Areas On On One! 


Type ID Adv Rtr 
Link 0105056 Ls LOE. 
Link 0.0.0.7 2s LG 





aliniceuciteicr ie— 1/1/00 Mesa 0.0.0.1 












































Type ID Adv Rtr 
Link 20505057 LOZ » ILS). 
Link 0.0.0.8 LV 6 IGS. 
user@2> show ospf3 route 
Prefix 
U2 , UGS. 051 

NH-interface (null), NH-addr feee:: 
U2 9 MOS 4 dhs 

NH-interface at-—0/3/1.0 
UO? , WS, 351 

NH-interface so-0/2/0.0 
U2 . WS, 4 5 I 

Nestoria cmprce/mll/a( nn) 
JOODs Le e/ G4 

NH-interface so-0/2/0.0 
MOVs g2/ 128 

NH-interface so-0/2/0.0 
SOO e2 3 3/4 

NH-interface at-—0/3/1.0 
VOOMS 2s g2z/ 128 

NH-interface at-—0/3/1.0 
9009:3::/64 

NH-interface so-0/2/0.0 
9009:4::/64 

NH-interface fe-1/1/0.0 
WOO9ssss/ 4 

NH-interface so-0/2/0.0 

NH-interface fe-1/1/0.0 
9009:6::/64 

NH-interface fe-1/1/0.0 

















DOO Ooi e218 


Seq 
0x80000091 
0x80000091 


Seq 
0x80000092 
0x80000092 


Seq 
0x80000092 
0x80000091 


Pa 


clo) 


Type 


In 


1032558 713s 


In 


IEigt 


ILigt 


elem} 


dCi 


In 


In 


IEigt 


In 


clara} 


E1e6e! 


Calc 


E166e! 


E1ee) 


Cle 


tra 


E1ee! 


Ele 


E1ee! 


Ele! 





Elexel 


Inter 


Inter 


Route 


Type 


Router 


Router 


Area BR 


Area BR 


etwork 


etwork 


etwork 


etwork 


etwork 


etwork 











etwork 


Network 


Network 


Age 
1770 
1890 


Age 
2452 
2453 


Age 
2077 
2172 


NH 


Ty 
IP 





a2 


i012 





ae 


able 


Cksum Len 
Oxaecd 56 
Ox80£3) 56 


Cksum Len 
0x6018 56 
Ox3a3d 56 


Cksum Len 
Ox8de7 56 
Ox8ce5 56 


Metric 


pe 
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Admin Link Proto 


up 


up 


up 


NH-interface fe-1/1/0. 

feee::10:255:71:1/128 
NH-interface at-0/3/1. 

PESOS SILOS2S Sea TiI1s 3/128 
NH-interface so-0/2/0. 

feee::10:255:71:4/128 
NH-interface so-0/2/0. 

PSSSS CIOS 25S5e 716 5/128 
NE—AMESIEACS 1S—11//11/0, 

PESSS SILOS 255e7 136/128 
NH-interface fe-1/1/0. 

FSEOR SILOS 255R Vig 11/128 
NH-interface 100.0 

user@2> show interfaces terse 

Interface 

ies / 24 

sO—0/ 2/0. 

fe-1/1/0.0 

ate=0/ 3/0 

100 

100.0 


Device 3 Status 


Purpose 


Verify that Device 3 has learned the expected routes and has established the expected neighbor adjacencies. 


Action 


up 


user@3> show ospf3 interface 


Interface 
SOm Oss / Zee 
Wil=19Z 16 
WL=192. 16 
HO ORO 





State 
0 Pie Welt. 
S64 od Pic OMEN 
SoHo Piehorite 
DRother 


up 


up 


up 


up 


Area 


joy Xo 1S) 


ey, (Ss) Sy © 


al 


Es = =) 


inet6 


inet6é 


net6 


inet 


inet6 

















Intra twork iF 
Intra twork TF 
intra twork IP 
Intra twork ine 
Inter twork i: 
Inire twork IP 
Local 
GOODS 323 i /Ga 
fe80::2a0:a514:0:84c/64 
SUOSE AR aW/iG4 
fe80::2a0:a514:0:94c/64 


NMHNIG32 3 92a 
fe80::2a0:a514:0:c4c/64 


192, 168 525 i 
fe80::2a0:a50f:fc56:14c 


re Seecel! Ono replace lias 


DR ID 
ORO 
ORORIOR 
0.0.0 
0.0.0 


Sy XSF XS) (S) 


BDR 


a 2a © 


Sy) Sb 1S) © 


--> 


10)B) 


yo a © 


Sy KSk Sy (S) 


Remote 


0/0 


Nbrs 


OrRFR 


188 


189 





























el —O/2/ 1.0 Pevere O.0,0.1 CRO RnO RO) CRO RnO RO 1 
SOm 0/7 OmO Petere O.0.0.4 ORO RORO) ORO RORO iL 
user@3> show ospf3 neighbor 
ID Interface State Pie aL Dead 
192, 1680 A SOn 0) S720) Full 128 eal 
Neighbor-address fe80::2a0:a514:0:14c 
192.168.2511 WlH192 16S 42.1 Full 0 33 
Neighbor-address 9009:3::1 
192.168.4511 yiH192 163 .4.1 Full 0 SS 
Neighbor-address 9009:5::2 
192,168.41 cl =—0/ 2/1 0 Full 128 30) 
Neighbor-address fe80::2a0:a514:0:44c 
U2 5 WS 5 Zod so-0/3/0.0 Full IS) 37 
Neighbor-address fe80::2a0:a514:0:84c 
user@3> show ospf3 database 
meee OU ,0.0 
Type ID Adv Rtr Seq Age Cksum Len 
Router OROr ORE) 192,168,061 0x80000090 sl nD -4. Loa 20) 
Router OPFOR OPO) 192,168,161 0x80000090 12 0x503e 40 
Router OROr ORO) 192,168,261 0x80000091 6S ObeSees 56 
Router “0.05050 192 168.341 0x80000093 255 O0x26e V2 
Router OROR ORO) 192 168.461 0x80000090 163 Ox6el7 40 
Hbravis esa Avis Petes au Oey OPO 192,168,261 0x80000093 1382 Oxfc5c 36 
InterArPtx 0.0.0.2 192, 168.251 0x80000093 1194 Qx156 36 
inim@eeueaPiee 0) ,0.0 53 192 1G. 2el 0x80000092 2882 Ox3l1la4 44 
InterArPfx 0.0.0.4 192,168,261 0x80000090 819 Oxc320 44 
ImeeeNe 00.0.5 192 168.261 0x80000092 1007 Oxf85a 36 
InterArPfx 0.0.0.6 192,168.21 0x80000091 632 Oxelfc 44 
InterArPfx *0.0.0.1 192 168.361 OXSOOOOONs Leis WxEHG2 36 
interArPEx *0. 0.052 192,168,361 0x80000094 1005 Ox64e 36 
limes. 00.0.3 192 1685361 0x80000092 2880 Oxbc26 44 
imeeueaPiexs *7(0),0 0,4 192, 168.361 0x80000090 818 Ox2aaa 44 
imeem “0.0.0.5 192,168.31 0x80000091 1380 Oxe56e 36 
InterArPfx *0.0.0.6 192, 168.361 0x80000090 443, Oxdc02 44 
nena Aversa Ol ORiOhee 192.168.4. 0x80000092 1945 Oxf461 36 
iimeereaae< O.,0,0.3 L2G, a. 0x80000092 1757 Oxf85b 36 
InterArPfx 0.0.0.4 192, 1G 4. 0x80000091 1570 Oxfe54 36 
slate ere Avra stan OP Ont Ons) 192, 168.461 0x80000090 2976 Oxd906 44 
InterArPfx 0.0.0.6 192, 168.464 0x80000090 820 Oxefec 44 
InterArPfx 0.0.0.7 192,168.41 (0:4: 10) 01010) 0ho st ay) nc PO >-¢ Loko Lo EEG 
InterArPfx 0.0.0.8 19? 168.461 0x80000090 632 O0x8d50 44 
InterArPfx 0.0.0.9 192,168.41 0x80000091 445 Oxeede 44 




















InterArPEx 0.0.0.10 LGV » ISS). 
limcwevaePin< 0010.1 LA 6 GIS). 
LimcwevaselPine 0), 10,10). 4 LG) 5 LG 5 
lmctwevaePin< 0.010. 1 LV 6 UGS 
TIME EVA IES 1050) 010511 LS) LOS « 
meee. O00. 

Type ID Adv Rtr 
Router OR OR ORO) 25 LOE 
Router 0,050.0 L924, 168, 
Router 0.0.0.0 NZ, 4 ALS}: 
InterArPEx 0.0.0.1 LE) LOS « 
Imeem 0.041053 LS) » ILS). 
InterArPf=x 0.0.0.4 LV 6 ISIS 
LimeGuesuelPiese (0) (0) 510). 1 LGV) LSS 
limc@iwaePin<e “0.0.0.3 LGV 6 UGS 5 
InterArPfEx *0.0.0.4 LE LOS . 
InterArPEx 0.0.0.1 LV » ISS) 
InterArPEx 0.0.0.3 LE LOS . 
InterArPfx 0.0.0.4 LGA, GSS 5 
limcwevaTePin< 0.010, 1 LV 6 UGS 
Lime wevuelPinse 10) (0.10). 1 IV 3 ALS 
TIME EVIE I 10 40.4105 1 LEV 5 IOS). 
interface so-0/3/2.0 Area 0.0.0.0 





Type ID Adv Rtr 
Link O.05,052 125 ALG 
Link =O,0.058 12. OS. 





interface t1-0/2/1.0 Area 0.0.0.1 


Type ID Adv Rtr 
Link 0,050.9) LAs LO. 
Link 0.0.0.7 IZ Or 





interface so-0/3/0.0 Area 0.0.0.1 





Type ID Adv Rtr 
Link OPOPIOREG LQ2 , WSS. 
Link “0,0.,.0.7 AA. WSS 5 
user@3> show ospf3 route 
Prefix 
192,168 .0.1 


NH-interface so-0/3/2.0 


(oy [sy I SSS 


HS COEDS SCO COCO) SDS NOOR iS Gos eho: 


PPP PP 





Type 
Intra Router 


Ox8000008£ 
0x80000095 
0x80000096 
0x80000096 
0x80000097 


seq 
0x80000093 
0x80000094 
0x80000092 
0x80000094 
0x80000090 
Ox8000008F 
0x80000094 
0x80000090 
Ox8000008F 
0x80000093 
0x80000090 
Ox8000008F 
0x80000097 
0x80000099 
0x80000098 





seq 
0x80000091 
0x80000091 


seq 
0x80000092 
0x80000092 


Seq 
0x80000092 
0x80000092 


Path Route 


Type 


SIS 
sls O pie 
LOL 
1944 
Pr Ssllts} 


Age 
Za3) Th 

68 
25) 
LEST 
444 
L562) 
1943 
630 
1755 
1663 
S13 
1476 
2507 
L1L3 
2320 


Age 
AQAA 
2505 


Age 
2ASO 
2507 


Age 
2694 
2693 


NH 


Ty 
IP 





Oxac5a 44 
Oxbda0 64 
Ox85d7 64 
Oxc7bd 64 
Ox93f0 64 
Cksum Len 
Ox8f62 56 
OxSTD cm S 
0x8768 56 
Oxec6c 36 
Ox994d 44 
Oxd839 44 
Oxd781 36 
Oxe002 44 
Oxc34e 44 
Oxt9sio 36 
Oxed1 44 
Oxe824 44 
Ox6bf1l 76 
Oxadb8 76 
Ox3c26 76 
Cksum Len 
Osc Oe VIS 
Ox84£9 56 
Cksum Len 
Ox1661 56 
OxSi3s fae oIG 
Cksum Len 
Ox6018 56 
Ox3a3d 56 

Metric 
pe 

‘iL 
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WED 4 WG}, Is Intra 
NE—sbicSmirace (iam), Nemes ineees SMe A255e 71 3 iil 
U2 5 WSS 5 25 1 emitertact 
NH-interface so-0/3/0.0 

U2 , WES s451 Lime 16e) 
NH-interface t1-0/2/1.0 

QMOOOg is 3/64 Intra 
NH-interface so-0/3/2.0 

VOOIMs 1s 2/128 Intra 
NH-interface so-0/3/2.0 

WO OC eae Ao4 Intra 
NH-interface so-0/3/0.0 

VOODL2s 32/128 Intra 
NH-interface so-0/3/0.0 

QOOIs Ses /S4 Intra 
NH-interface so-0/3/0.0 

9009:4::/64 Intra 
NH-interface so-0/3/0.0 
NH-interface t1-0/2/1.0 

HOON 3 / G4 Intra 
NH-interface t1-0/2/1.0 

QUOI 6337/64 Inter 
NH-interface t1-0/2/1.0 

MOIRGs 3 1/128 Inter 
NH-interface t1-0/2/1.0 

feee::10:255:71:1/128 Intra 
NH-interface so-0/3/0.0 

feee::10:255:71:3/128 Intra 
NH-interface 100.0 

feee::10:255:71:4/128 Intra 
NH-interface so-0/3/2.0 

feee::10:255:71:5/128 Intra 
NE—amESireee icil—0/2/ il ,O 

feee::10:255:71:6/128 Inter 
NH-interface t1-0/2/1.0 

FSEO8 SIO s255R fig 1/128 Intra 
NH-interface so-0/3/0.0 

user@3> show interfaces terse 

Interface Admin Link Proto Local 

Le=1 2/0 

soO-0/ 3/2 0 up up inet6 


el-0/2/1,0 up up inet6 


Router 


Area BR 


Area BR 


etwork 


etwork 


etwork 


etwork 


etwork 











etwork 


etwork 


etwork 


etwork 


etwork 


etwork 


etwork 


etwork 


etwork 











etwork 


QOWOMg 13 92 / oA 
£e80::2a0:a514:0:24c/64 
9009:5::1/64 


ae 


EP. 


a2 


a2 





ablS 


able 


a2 
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so-0/3/0.0 


100 
oO «0 


Device 4 Status 


Purpose 


Verify that Device 4 has learned the expected routes and has established the expected neighbor adjacencies. 


Action 


up 


up 


user@4> show ospf3 interface 


up 


up 


Arsa 


inet6 


inet 


inet6 


DRother 0.0.0.1 





Interface State 
100.0 

fe-1/1/0.0 PtToPt 
EL-O/ 2/10 Pie ILO Ne. 
fe-0/0/0.0 Pie hort 
WIL=1L92 , WSS 4 Sod Pic WORN 
user@4> show ospf3 neighbor 

ID Interface 
192,168.42. 1 fe-1/1/0.0 





LOA 5 WOE} 5 Ss dL 


el=O/2/ 150) 





LY 5 LOS} 4 5 IL 


fe-0/0/0.0 











LY 5 WOS5 Ss I 








user@4> 


Area 0.0.0.0 


Type 
Router 
Router 
Router 


Router 


oy io, ev © 


Se ec S&S & 


oe (So © © 


WIL 92 , 6s 


show ospf3 database 


Se ec Sc = 


ORO Oks 


al 


ORIORORer 
Wo05052 
50,050 


ain al 


Neighbor-address 9009:5::1 


Adv 


LOZ « 
IOI2e 
Ls 
IZ 


Neighbor-address fe80::2a0:a514:0: 


Neighbor-address fe80::2a0:a514:0: 


Neighbor-address fe80::2a0:a514:0: 


RUG Ie 


168. 
ALOIS 
LOIS. 
LOIS 5 


fe80::2a0:a514:0:34c/64 


9009:3::2/64 


ese ZaOiabiA Oi 4/64 


IL 6 UGS 5 3} 5 AL 


==> 0/0 


SSO S S2a0) 2 aaObe s icelaS 9 ilave 
feee::10:255:71:3 


DR ID 


0. 


ORO 0 


0.0.0.0 


0. 
OF 
0. 


State 

Full 
94c 

Full 
34c 

iwi 
64c 

iwi aL 


WN FO 
PPP PR 


0.0.0 
0.0.0 
ORLORIO) 


Pri 


128 


128 


128 


Seq 
0x80000090 
0x80000090 
0x80000091 
0x80000093 


BOR ID 
ORO RO FO) 
0.0.0.0 
0.0.0.0 
ORLORORO 
OROROR TO 


Dead 
35 


34 


39 


33 


Age 
270 
Za It Al 
328 
514 


Cksum 
Ox6c22 
0x503e 
0x9c63 
Ox26e 


Len 


40 
40 
56 
2 


Nbrs 


192 


Router 


In 
In 
In 
In 
gy 
In 
In 
iy 
In 
In 
In 
In 
in 
In 
In 
ale) 
aigy 
In 
ay 
iy 
In 
In 
in 
In 
in 


Area 0.0. 





Type 
Router 


Router 


Router 


iy 
ayy 
In 
an 
L1G 3) 
In 
In 
iy 
In 
In 
a) 
In 





terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
traArPf 
EieevArel2 Ic 


traArPf 





traArPf 


terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
terArPf 
traArPf 


traArPf 





traArPf 


x x ~*~ x Me KM Ke M KE M MH MR KM KM MH KM KM MH MR M KM M KM KM KM 


Bee Ee Ee 
ey (oe, 1, (S) ©) i Ye jr ~S 


(0), 


+ 
ie) 


oS ~) Yer fo) ey or oe @ fj ver jr 


ey oe, eo je eo aS aS S&S 


ee 
SS oS oS & & 


eS oe So oe ec Ee Ss So ec ee S&S oS Se es ec Sc & oS oS eS eS ES S&S 


eS @ 2S S&S ec ce GS o&S oS Sc eS ec S&S & 


oo So ea 2 2S & & ec ec eo 2 S&S oS oS ec 2 f= ff] S&S ec 2c Se |] & S| © 


es Se eo oa 2 oS LS Se ce ec 2 S| 2 2 S&S 


i i i ey ok Se) eS OS) ey aS SIS) ey aS SSS 
fo) 


PPP oO® WOW FP B® WOW FP B® WF OO oO 


LOZ 
O27 
1 
1927 
LY 
LZ « 
LN 
lho27 
IZ 
12 
LZ « 
LY 
LZ « 
O27 
InoI27: 
IOI27 
lbSIZe 
LZ 
LZ 
1g2F 
IZ" 
IF 
LZ « 
LY) 
LZ « 
92 


Adv 


LZ 
LY 
UgI27 
127 
12 
LZ 
LY 
LZ « 
O27 
Ung27 
192" 
LN) 
LZ « 
LY 
127 


168. 
AL SIeh.5 
168. 
LOIS. 
LHS) 6 
168. 
168. 
168. 
ALIS 5 
LOIS 
168. 
LOIS) « 
168. 
LG. 
168. 
Ae 5 
LORS) 
168. 
LHS) « 
168. 
LOIS 
168. 
168. 
LHS} 6 
168. 
AGS 5 


IRUE Te 


168. 
LHS) 
LOIS 
AL SIeh. 5 
LOS. 
168. 
LOIS) « 
168. 
LISS 5 
nGige 
ALIS 
LOIS) 6 
168. 
LOS « 
LOIS 





(Gay (G8) {G8} os) es) Sy ey SS) Rey eS) ES) SS 


Ss Ss 


Ss 





Gs) hs) i 1S 


fis (Gd) (Se) iss de ss Gy) Go Gy RS ES) eS) ss a I 





0x8000 
0x8000 


0090 
0093 


0x80000093 


0x8000 
0x8000 
0x8000 
0x8000 


0093 
0090 
0092 
0091 


0x80000093 


0x8000 


0094 


0x80000093 


0x8000 
0x8000 
0x8000 
0x8000 


0090 
0091 
0090 
0092 


0x80000092 


0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 





0091 
0091 
0090 
0091 
0090 
0091 
OO8t 
0095 
0096 
0096 


0x80000097 


seq 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 
0x8000 





0093 
0094 
0092 
0094 
0090 
OO8E 
0094 
0090 
OO8E 
0093 
0090 
OO8E 
0097 
0099 


0x80000098 


420 
1641 
1453 

141 
1078 
1266 

891 
U2 7 
1264 

138) 
LOWY 
16S) 

7102 
2202 
2014 
1827 

23S) 
LOWY 
SK) 2) 

889 

7102 
UGSS) 
1270 
127A 
Paga\Q) 3) 
ZB TY 


Age 
Bails) 
SAT 
514 
2015 
702 
Wg 7 
2202 
889 
2014 
1920 
AO) 
1733 
Zu6S) 
1452 
ZS T 


Ox6el7 
OxsRe ae! 
0x156 

Ox2fad 
0xc320 
Oxf85a 
Oxelfc 
Oxf562 
Ox64e 

Oxba27 
Ox2aaa 
Oxe56e 
Oxdc02 
Oxf461 
Oxf85b 
Oxfe54 
Oxd707 
Oxefec 
Oxbc95 
0x8d50 
Oxeede 
OxacdSa 
Oxbda0 
0x85d7 
Oxc7bd 
0x93£0 


Cksum 

Ox8f£62 
0x37b8 
0x8768 
Oxec6c 
0x994d 
0xd839 
Oxd781 
Oxe002 
Oxc34e 
0x193b 
Oxed1 

Oxe824 
Ox6bf1 
Oxadb8 
0x3c26 


40 
36 
35 
44 
44 
36 
44 
36 
36 
44 
44 
36 
44 
36 
36 
36 


Ss 


Ss 


Ss 
Ss 





64 
64 
64 
64 





Len 


Ss 
Ss 








Ss 
Ss 


76 
76 
76 
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Area 0.0.0.2 





Type ID Adv Rtr 
Router 0.0.0.0 192,168. 
Router ORO FOr) IY) 5 LORS} 
InterArPEx *0.0.0.1 LEV » ILO 
Timers 10) 50) «1052 LE, LOS. 
imegueswePin <0). .10,3 LV 5 LOE. 
iG alge ay Waa) = >. eauacadl Ol O i O-4 LGA 6 IGS. 
lenis Aira bstexauct OF ORS OREO) WA LO. 
InterArPEx *0.0.0.6 NZ, 4 ALS 
IiMeGTANI se 1050) a0 2 7 LE . LOS. 
Time Gra ATeleiexe ~*(0)4(0) 105 2) NZ 5 ALS} 
InterArPfx *0.0.0.11 LA 6 GIS. 
Uimeguatwaeit< (0) 10). (0). ibe LGV) 6 ALG 
Homie ye Avra stexqun Oe OR Oelts LGV 6 ISIS 5 
InterArPEx *0.0.0.14 LE LOS. 
Time weVAIEIPiEse ~*(0) . (0.410), A LV » ILS) 
IMC HeVACP I< 050) 0101 LEZ LOS . 
interface fe-1/1/0.0 Area 0.0.0.1 





Type ID Adv Rtr 
Link OROR AO Ra, NZ 5 USS 4 
Link “OO 5058 WY 5 LOSS 





interface t1-0/2/1.0 Area 0.0.0.1 


Type ID Adv Rtr 
Link OR OR OR LZ. UO. 
Link 2050 005 7/ LY 5 LOSS 





interface fe-0/0/0.0 Area 0.0.0.2 


Type ID Adv Rtr 
Link “O10 .00.6 AZ 5 LOE. 
Link O0.0,052 WA LO 





user@4> show ospf3 route 


Prefix 


UA 5 WO} 5 0) 5 AL 


NH-interface (null), NH-addr feee: 


192,168, i, 0 
NH-interface (null), NH-addr feee: 
192,168,251 


NH-interface fe-1/1/0.0 

















seg 
4.1 0x80000091 
Dye db 0x80000090 
4.1 0x80000094 
4.1 0x80000094 
4.1 0x80000093 
4.1 0x80000091 
4.1 0x80000090 
4.1 0x80000091 
4.1 0x80000090 
4.1 0x80000090 
4.1 0x80000090 
4.1 0x80000090 
4.1 Ox8000008F 
4.1 Ox8000008F 
4.1 0x80000098 
Die dl 0x80000095 
Seq 
Zo AL 0x80000092 
Areal: 0x80000091 
seq 
Bo dl 0x80000092 
Apel! 0x80000092 
Seq 
Al ib 0x80000092 
Beal 0x80000091 
Path Route 
Type Type 
IiMeies! INGE SIE 
gLOSA2SS5e Hie s 
Iimetee) IONE Se 
BLOWS Bass Wil S 
iiimicsee! JACSEl TEI 


Age 
45 
DUO 
DEOS 
2108 
139) 
2483 
B83) 
795 
1545 
1353 
608 
B27 
1452 
1264 
2858 
12°70 


Age 
27 
2670 


Age 
2389 
2764 


Age 
DOS 2 
22110 


Cksum 

0x4741 
0x3a50 
Oxfad5a 
Oxfed54 
Oxe7£6 
Oxdava 
Oxab35 
Oxdc3 

Oxa2b2 
Ox9cb5 
Ox8£49 
Ox37a3 
0x689e 
0x6c98 
0x82f£5 
Oxf25a 


Cksum 
Ox8de7 
Ox8ce5 


Cksum 
Ox1661 
Ox383f 


Cksum 
Ox79Ee 
Oxblc7 





Len 
40 
40 
36 
36 
44 
Sis 
44 
44 
Si6 
36 
44 
44 
44 
44 
64 
64 


Len 
56 
56 


Len 
56 
56 


Len 
56 
56 


H Metric 


194 


195 































































































UE! . WS. 35d Intra Area BR die al 
NE—amESitece icil—0/2/ i .0 

U2 5 WSS 5 D5 I Intra Router die Al 
NH-interface fe-0/0/0.0 

MORI ss /6e Intra Network IP 2 
NH-interface t1-0/2/1.0 

MOOI Le a2/l2s Intra Network IP iL 
NH-interface t1-0/2/1.0 

VOOMs ze 2 /Ge Intra Network IP z 
NH-interface fe-1/1/0.0 

MOOV 28 32/ 1a Intra Network IP ‘lL 
NH-interface fe-1/1/0.0 

WOOO Sisy/.64 Intra Network IP 2 
NE—amEeSirace icil-0/2/ i ,0 
NH-interface fe-1/1/0.0 

9009:4::/64 Intra Network IP iL 
NH-interface fe-1/1/0.0 

QOOIs Ss 3/64 Intra Network IP ‘lL 
NH-interface t1-0/2/1.0 

QOON8Ses 3/4 Intra Network IP 1 
NH-interface fe-0/0/0.0 

QOOMeSe gi / LAs Intra Network IP 0 
NH-interface fe-0/0/0.0 

feee::10:255:71:1/128 Intra Network IP 2 
NH-interface fe-1/1/0.0 

feee::10:255:71:3/128 Intra Network IP il 
NH-interface t1-0/2/1.0 

feee::10:255:71:4/128 Intra Network IP 2 
NH-interface t1-0/2/1.0 

feee::10:255:71:5/128 Intra Network IP 0 
NH-interface 100.0 

feee::10:255:71:6/128 Intra Network IP il 
NH-interface fe-0/0/0.0 

feee::10:255:71:11/128 Intra Network Iie il 
NH-interface fe-1/1/0.0 








user@4> show interfaces terse 


Interface Admin Link Proto Local Remote 

Lie=1/2./C 

tl-O/ 2/0 up up inet6 VOOM es 59 2/4 
fe80::2a0:a514:0:44c/64 

fe-0/0/0.0 up up inet6 9009:6::1/64 


fe80::2a0:a514:0:54c/64 
fe-1/1/0.0 up up inet6 9009:4::2/64 
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fe80::2a0:a514:0:a4c/64 
100 
CORO) up up inet 192 1684.0 === 0/0 
inet6 CSSOS BZAORADOIE SESS 9 Ae 
feee::10:255:71:5 


Device 5 Status 


Purpose 


Verify that Device 5 has learned the expected routes and has established the expected neighbor adjacencies. 


Action 


user@5> show ospf3 interface 


Interface State Area Die eb) BDR ID Nbrs 
100.0 DRe thes sO On On ORO ORO OR ORONO 0 
fe-0/0/0.0 PELOre  O.0.0.2 OR ORORO OR OROrR 0 al 


user@5> show ospf3 neighbor 

ID Interface State iea Dead 

U2 M68 451 fe-0/0/0.0 Full 128 34 
Neighbor-address fe80::2a0:a514:0:54c 





user@5> show ospf3 database 
Area 0.0.0.2 











Type ID Adv Rtr Seq Age Cksum Len 
Router OROR ORO) 192 168.464 0x80000091 509 0x4741 40 
Router 0.0.0.0 192,168,561 0x80000090 732 Ox3a50 40 
InterArPfx 0.0.0.1 192,168.41 0x80000094 2759 Oxfa5a 36 
InterArPfx 0.0.0.2 192, 16.451 0x80000094 2572 Oxfe54 36 
Imeem O50 5065 192, 168.46i 0x80000093 603 Oxe7f£6 44 
imrercscint< 0.0.0.4 192,168.41 0x80000091 2947 Oxda7a 36 
ImcewNee2 O0 5.055 192 168.461 0x80000090 1447 Oxab35 44 
InterArPfx 0.0.0.6 192,168.41 OS OO OOO S15 Odes 44 
InterArPfx 0.0.0.7 ODT eS Aarel: 0x80000090 2009 Oxa2b2 36 
alitaits eis Aura era OOF Ol) 192,164 oi 0x80000090 1822 O0x9cb5 36 
meee O00 11 192. 168.4.4 0x80000090 1072 Ox8f49 44 
ImeecAaee< 0.0.0, 12 192 163.464 0x80000090 791 Ox37a3 44 
InterArPfx 0.0.0.13 192,.168.4.1 Ox8000008£ 1916 Ox689e 44 
InterArPfx 0.0.0.14 ODT Ae Sire: Ox8000008£ 1728 Ox6c98 44 
Wine eevaraeiese (0) (0), (0), aL L924, 1634, i 0x80000099 322 Ox80f6 64 
imcweaNMePing “O50 ,051 192,168,561 0x80000095 1732 Oxf25a 64 

















interface fe-0/0/0.0 Area 0.0.0.2 





Type ID Adv Rtr 
Link OR ORORG LSA. WSIS 6 a al 
Link “0.05052 192 16S. Sel 
user@5> show interfaces terse 
Interface Admin Link Proto 
Lies /2/C 
fe-0/0/0.0 up up inet6 
100 
100.0 up up inet 

inet6 


RELATED DOCUMENTATION 


OSPF Overview | 23 
OSPF Packets Overview | 28 
Understanding OSPF Configurations | 35 
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Seq Age Cksum Len 
0x80000093 416 Ox77fd 56 
ORJOOOOODL 2IS2 Oxoley 56 

Local Remote 


9009:6::2/64 
fe80::2a0:a514:0:64c/64 


192,168 55. 1 --> 0/0 
fe80::2a0:a50f:fc56:14c 
feee::10:255:71:6 
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Configuring OSPF Route Control 


IN THIS SECTION 


Understanding OSPF Route Summarization | 199 


Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements Sent into the Backbone 
Area | 200 


Example: Limiting the Number of Prefixes Exported to OSPF | 207 
Understanding OSPF Traffic Control | 209 

Example: Controlling the Cost of Individual OSPF Network Segments | 211 
Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217 
Example: Controlling OSPF Route Preferences | 220 

Understanding OSPF Overload Function | 222 

Example: Configuring OSPF to Make Routing Devices Appear Overloaded | 224 
Understanding the SPF Algorithm Options for OSPF | 228 

Example: Configuring SPF Algorithm Options for OSPF | 229 

Configuring OSPF Refresh and Flooding Reduction in Stable Topologies | 232 
Understanding Synchronization Between LDP and IGPs | 234 

Example: Configuring Synchronization Between LDP and OSPF | 234 

OSPFv2 Compatibility with RFC 1583 Overview | 238 


Example: Disabling OSPFv2 Compatibility with RFC 1583 | 239 


| Understanding OSPF Route Summarization 


Area border routers (ABRs) send summary link advertisements to describe the routes to other areas. 
Depending on the number of destinations, an area can get flooded with a large number of link-state records, 
which can utilize routing device resources. To minimize the number of advertisements that are flooded 
into an area, you can configure the ABR to coalesce, or summarize, a range of IP addresses and send 
reachability information about these addresses in a single link-state advertisement (LSA). You can summarize 
one or more ranges of IP addresses, where all routes that match the specified area range are filtered at 
the area boundary, and the summary is advertised in their place. 


For an OSPF area, you can summarize and filter intra-area prefixes. All routes that match the specified 
area range are filtered at the area boundary, and the summary is advertised in their place. For an OSPF 
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not-so-stubby area (NSSA), you can only coalesce or filter NSSA external (Type 7) LSAs before they are 
translated into AS external (Type 5) LSAs and enter the backbone area. All external routes learned within 
the area that do not fall into the range of one of the prefixes are advertised individually to other areas. 


In addition, you can also limit the number of prefixes (routes) that are exported into OSPF. By setting a 
user-defined maximum number of prefixes, you prevent the routing device from flooding an excessive 
number of routes into an area. 


Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements 
Sent into the Backbone Area 


IN THIS SECTION 


Requirements | 200 
Overview | 200 
Configuration | 201 


Verification | 206 


This example shows how to summarize routes sent into the backbone area. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a static route. See Examples: Configuring Static Routes in the Junos OS Routing Protocols Library. 


Overview 


You can summarize a range of IP addresses to minimize the size of the backbone router’s link-state database. 
All routes that match the specified area range are filtered at the area boundary, and the summary is 
advertised in their place. 
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Figure 18 on page 201 shows the topology used in this example. R5 is the ABR between area 0.0.0.4 and 
the backbone. The networks in area 0.0.0.4 are 10.0.8.4/30, 10.0.8.0/30, and 10.0.8.8/30, which can be 
summarized as 10.0.8.0/28. R3 is the ABR between NSSA area 0.0.0.3 and the backbone. The networks 
in area 0.0.0.3 are 10.0.4.4/30, 10.0.4.0/30, and 10.0.4.12/30, which can be summarized as 10.0.4.0/28. 
Area 0.0.0.3 also contains external static route 3.0.0.8, which will be flooded throughout the network. 


Figure 18: Summarizing Ranges of Routes in OSPF 
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In this example, you configure the ABRs for route summarization by including the following settings: 


e area-range—For an area, summarizes a range of IP addresses when sending summary intra-area link 
advertisements. For an NSSA, summarizes a range of IP addresses when sending NSSA link-state 
advertisements (Type 7 LSAs). The specified prefixes are used to aggregate external routes learned 
within the area when the routes are advertised to other areas. 


e network/mask-length—Indicates the summarized IP address range and the number of significant bits in 
the network mask. 


Configuration 


CLI Quick Configuration 
e To quickly configure route summarization for an OSPF area, copy the following commands and paste 
them into the CLI. The following is the configuration on ABR R5: 


[edit] 

set interfaces fe-0/0/1 unit O family inet address 10.0.8.3/30 
set interfaces fe-0/0/2 unit O family inet address 10.0.8.4/30 
set interfaces fe-0/0/0 unit O family inet address 10.0.2.3/30 
set interfaces fe-0/0/4 unit O family inet address 10.0.2.5/30 
set protocols ospf area 0.0.0.4 stub 

set protocols ospf area 0.0.0.4 interface fe-0/0/1 

set protocols ospf area 0.0.0.4 interface fe-0/0/2 

set protocols ospf area 0.0.0.0 interface fe-0/0/0 

set protocols ospf area 0.0.0.0 interface fe-0/0/4 

set protocols ospf area 0.0.0.4 area-range 10.0.8.0/28 


e To quickly configure route summarization for an OSPF NSSA, copy the following commands and paste 
them into the CLI. The following is the configuration on ABR R3: 


[edit] 

set interfaces fe-0/0/1 unit O family inet address 10.0.4.10/30 
set interfaces fe-0/0/2 unit O family inet address 10.0.4.1/30 
set interfaces fe-0/0/0 unit O family inet address 10.0.2.1/30 
set interfaces fe-0/0/4 unit O family inet address 10.0.2.7/30 
set protocols ospf area 0.0.0.3 interface fe-0/0/1 

set protocols ospf area 0.0.0.3 interface fe-0/0/2 

set protocols ospf area 0.0.0.0 interface fe-0/0/0 

set protocols ospf area 0.0.0.0 interface fe-0/0/4 

set protocols ospf area 0.0.0.3 area-range 10.0.4.0/28 

set protocols ospf area 0.0.0.3 nssa 

set protocols ospf area 0.0.0.3 nssa area-range 3.0.0.0/8 


Step-by-Step Procedure 


To summarize routes sent to the backbone area: 


1. Configure the interfaces. 


NOTE: For OSPFv3, include IPv6é addresses. 


[edit] 

user@R5# set interfaces fe-0/0/1 unit O family inet address 10.0.8.3/30 
user@R5# set interfaces fe-0/0/2 unit O family inet address 10.0.8.4/30 
user@R5# set interfaces fe-0/0/0 unit O family inet address 10.0.2.3/30 
user@R5# set interfaces fe-0/0/4 unit O family inet address 10.0.2.5/30 
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[edit] 

user@R3# set interfaces fe-0/0/1 unit O family inet address 10.0.4.10/30 
user@R3# set interfaces fe-0/0/2 unit O family inet address 10.0.4.1/30 
user@R3# set interfaces fe-0/0/0 unit O family inet address 10.0.2.1/30 
user@R3# set interfaces fe-0/0/4 unit O family inet address 10.0.2.7/30 


2. Configure the type of OSPF area. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@R5# set protocols ospf area 0.0.0.4 stub 


[edit] 
user@R3# set protocols ospf area 0.0.0.3 nssa 


3. Assign the interfaces to the OSPF areas. 


user@R5# set protocols ospf area 0.0.0.4 interface fe-0/0/1 
user@R5# set protocols ospf area 0.0.0.4 interface fe-0/0/2 
user@R5# set protocols ospf area 0.0.0.0 interface fe-0/0/0 
user@R5# set protocols ospf area 0.0.0.0 interface fe-0/0/4 


user@R3# set protocols ospf area 0.0.0.3 interface fe-0/0/1 
user@R3# set protocols ospf area 0.0.0.3 interface fe-0/0/2 
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/0 
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/4 


4. Summarize the routes that are flooded into the backbone. 


[edit] 
user@R5# set protocols ospf area 0.0.0.4 area-range 10.0.8.0/28 


[edit] 
user@R3# set protocols ospf area 0.0.0.3 area-range 10.0.4.0/28 
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5. On ABR R3, restrict the external static route from leaving area 0.0.0.3. 


[edit] 
user@R3# set protocols ospf area 0.0.0.3 nssa area-range 3.0.0.0/8 


6. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


Configuration on ABR R5: 


user@R5# show interfaces 
fe-0/0/0 { 
unit O { 
family inet { 
address 10.0.2.3/32; 


} 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.8.3/32; 


} 
fe-0/0/2 { 
unit O { 
family inet { 
address 10.0.8.4/32; 


} 
fe-0/0/4 { 
unit O { 
family inet { 


address 10.0.2.5/32; 


user@R5# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/0.0; 
interface fe-0/0/4.0; 


area 0.0.0.4 { 
stub; 
area-range 10.0.8.0/28; 
interface fe-0/0/1.0; 
interface fe-0/0/2.0; 


Configuration on ABR R3: 


user@R3# show interfaces 
fe-0/0/0 { 
unit O { 
family inet { 
address 10.0.2.1/32; 


} 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.4.10/32; 


} 
fe-0/0/2 { 
unit O { 
family inet { 
address 10.0.4.1/32; 


} 
fe-0/0/4 { 
unit O { 
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family inet { 
address 10.0.2.7/32; 


user@R3t# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/0.0; 
interface fe-0/0/4.0; 
} 
area 0.0.0.3 { 
nssa { 
area-range 3.0.0.0/8 ; 
} 
area-range 10.0.4.0/28; 
interface fe-0/0/1.0; 
interface fe-0/0/2.0; 


To confirm your OSPFv3 configuration, enter the show interfaces and show protocols ospf3 commands. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Summarized Route 


Purpose 


Verify that the routes you configured for route summarization are being aggregated by the ABRs before 
the routes enter the backbone area. Confirm route summarization by checking the entries of the OSPF 
link-state database for the routing devices in the backbone. 


Action 


From operational mode, enter the show ospf database command for OSPF v2, and enter the show ospf3 
database command for OSPFv3. 
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| Example: Limiting the Number of Prefixes Exported to OSPF 


IN THIS SECTION 


Requirements | 207 
Overview | 207 
Configuration | 208 


Verification | 208 


This example shows how to limit the number of prefixes exported to OSPF. 


Requirements 


Before you begin: 


Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 


Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


By default, there is no limit to the number of prefixes (routes) that can be exported into OSPF. By allowing 


any number of routes to be exported into OSPF, the routing device can become overwhelmed and potentially 


flood an excessive number of routes into an area. 


You can limit the number of routes exported into OSPF to minimize the load on the routing device and 


prevent this potential problem. If the routing device exceeds the configured prefix export value, the routing 


device purges the external prefixes and enters into an overload state. This state ensures that the routing 


device is not overwhelmed as it attempts to process routing information. The prefix export limit number 
can be a value from O through 4,294,967,295. 


In this example, you configure a prefix export limit of 100,000 by including the prefix-export-limit statement. 
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Configuration 


CLI Quick Configuration 


To quickly limit the number of prefixes exported to OSPF, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. 


[edit] 
set protocols ospf prefix-export-limit 100000 


Step-by-Step Procedure 
To limit the number of prefixes exported to OSPF: 


1. Configure the prefix export limit value. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@host# set protocols ospf prefix-export-limit 100000 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
prefix-export-limit 100000; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 
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Verifying the Prefix Export Limit 
Purpose 


Verify the prefix export counter that displays the number or routes exported into OSPF. 


Action 


From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 


SEE ALSO 


Understanding OSPF Traffic Control 


Once a topology is shared across the network, OSPF uses the topology to route packets between network 
nodes. Each path between neighbors is assigned a cost based on the throughput, round-trip time, and 
reliability of the link. The sum of the costs across a particular path between hosts determines the overall 
cost of the path. Packets are then routed along the shortest path using the shortest-path-first (SPF) 
algorithm. If multiple equal-cost paths exist between a source and destination address, OSPF routes packets 
along each path alternately, in round-robin fashion. Routes with lower total path metrics are preferred 
over those with higher path metrics. 


You can use the following methods to control OSPF traffic: 


e Control the cost of individual OSPF network segments 
e Dynamically adjust OSPF interface metrics based on bandwidth 


e Control OSPF route selection 


Controlling the Cost of Individual OSPF Network Segments 


OSPF uses the following formula to determine the cost of a route: 


cost = reference-bandwidth / interface bandwidth 


You can modify the reference-bandwidth value, which is used to calculate the default interface cost. The 
interface bandwidth value is not user-configurable and refers to the actual bandwidth of the physical 
interface. 


By default, OSPF assigns a default cost metric of 1 to any link faster than 100 Mbps, and a default cost 
metric of 0 to the loopback interface (lo0). No bandwidth is associated with the loopback interface. 
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To control the flow of packets across the network, OSPF allows you to manually assign a cost (or metric) 
to a particular path segment. When you specify a metric for a specific OSPF interface, that value is used 
to determine the cost of routes advertised from that interface. For example, if all routers in the OSPF 
network use default metric values, and you increase the metric on one interface to 5, all paths through 
that interface have a calculated metric higher than the default and are not preferred. 


NOTE: Any value you configure for the metric overrides the default behavior of using the 
reference-bandwidth value to calculate the route cost for that interface. 


When there are multiple equal-cost routes to the same destination in a routing table, an equal-cost multipath 
(ECMP) set is formed. If there is an ECMP set for the active route, the Junos OS software uses a hash 
algorithm to choose one of the next-hop addresses in the ECMP set to install in the forwarding table. 


You can configure Junos OS so that multiple next-hop entries in an ECMP set are installed in the forwarding 
table. Define a load-balancing routing policy by including one or more policy-statement configuration 
statements at the [edit policy-options] hierarchy level, with the action load-balance per-packet. Then 
apply the routing policy to routes exported from the routing table to the forwarding table. 


Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth 


You can specify a set of bandwidth threshold values and associated metric values for an OSPF interface 
or for a topology on an OSPF interface. When the bandwidth of an interface changes, Junos OS automatically 
sets the interface metric to the value associated with the appropriate bandwidth threshold value. Junos 
OS uses the smallest configured bandwidth threshold value that is equal to or greater than the actual 
interface bandwidth to determine the metric value. If the interface bandwidth is greater than any of the 
configured bandwidth threshold values, the metric value configured for the interface is used instead of 
any of the bandwidth-based metric values configured. The ability to recalculate the metric for an interface 
when its bandwidth changes is especially useful for aggregate interfaces. 


NOTE: You must also configure a metric for the interface when you enable bandwidth-based 
metrics. 


Controlling OSPF Route Preferences 


You can control the flow of packets through the network using route preferences. Route preferences are 
used to select which route is installed in the forwarding table when several protocols calculate routes to 
the same destination. The route with the lowest preference value is selected. 
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By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a preference 
value of 150. Although the default settings are appropriate for most environments, you might want to 
modify the default settings if all of the routing devices in your OSPF network use the default preference 
values, or if you are planning to migrate from OSPF to a different interior gateway protocol (IGP). If all of 
the devices use the default route preference values, you can change the route preferences to ensure that 
the path through a particular device is selected for the forwarding table any time multiple equal-cost paths 
to a destination exist. When migrating from OSPF to a different IGP, modifying the route preferences 
allows you to perform the migration in a controlled manner. 


SEE ALSO 


OSPF Overview | 23 
Example: Controlling OSPF Route Preferences | 220 
Example: Configuring ECMP Flow-Based Forwarding 


Example: Controlling the Cost of Individual OSPF Network Segments 
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This example shows how to control the cost of individual OSPF network segments. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 
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e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Overview 


All OSPF interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes 
with lower total path metrics are preferred to those with higher path metrics. In this example, we explore 
how to control the cost of OSPF network segments. 


By default, OSPF assigns a default cost metric of 1 to any link faster than 100 Mbps, and a default cost 
metric of 0 to the loopback interface (lo0). No bandwidth is associated with the loopback interface. This 
means that all interfaces faster than 100 Mbps have the same default cost metric of 1. If multiple equal-cost 
paths exist between a source and destination address, OSPF routes packets along each path alternately, 
in round-robin fashion. 


Having the same default metric might not be a problem if all of the interfaces are running at the same 
speed. If the interfaces operate at different speeds, you might notice that traffic is not routed over the 
fastest interface because OSPF equally routes packets across the different interfaces. For example, if your 
routing device has Fast Ethernet and Gigabit Ethernet interfaces running OSPF, each of these interfaces 
have a default cost metric of 1. 


In the first example, you set the reference bandwidth to 10g (10 Gbps, as denoted by 10,000,000,000 
bits) by including the reference-bandwidth statement. With this configuration, OSPF assigns the Fast 
Ethernet interface a default metric of 100, and the Gigabit Ethernet interface a metric of 10. Since the 
Gigabit Ethernet interface has the lowest metric, OSPF selects it when routing packets. The range is 9600 
through 1,000,000,000,000 bits. 


Figure 19 on page 213 shows three routing devices in area 0.0.0.0 and assumes that the link between Device 
R2 and Device R3 is congested with other traffic. You can also control the flow of packets across the 
network by manually assigning a metric to a particular path segment. Any value you configure for the 
metric overrides the default behavior of using the reference-bandwidth value to calculate the route cost 
for that interface. To prevent the traffic from Device R3 going directly to Device R2, you adjust the metric 
on the interface on Device R3 that connects with Device R1 so that all traffic goes through Device R1. 


In the second example, you set the metric to 5 on interface fe-1/0/1 on Device R3 that connects with 
Device R11 by including the metric statement. The range is 1 through 65,535. 


Figure 19: OSPF Metric Configuration 


Area 0.0.0.0 





Configuration 


IN THIS SECTION 


@ Configuring the Reference Bandwidth | 213 
@® Configuring a Metric for a Specific OSPF Interface | 214 


Configuring the Reference Bandwidth 


CLI Quick Configuration 


To quickly configure the reference bandwidth, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configuration, copy and paste 
the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
set protocols ospf reference-bandwidth 10g 


Step-by-Step Procedure 


To configure the reference bandwidth: 


1. Configure the reference bandwidth to calculate the default interface cost. 
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NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf reference-bandwidth 10g 


TIP: As a shortcut in this example, you enter 10g to specify 10 Gbps reference bandwidth. 
Whether you enter 10g or 10000000000, the output of show protocols ospf command 
displays 10 Gbps as 10g, not 10000000000. 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


NOTE: Repeat this entire configuration on all routing devices in a shared network. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
reference-bandwidth 10g; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Configuring a Metric for a Specific OSPF Interface 


CLI Quick Configuration 

To quickly configure a metric for a specific OSPF interface, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. 


[edit] 
set protocols ospf area 0.0.0.0 interface fe-1/0/1 metric 5 


Step-by-Step Procedure 


To configure the metric for a specific OSPF interface: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Configure the metric of the OSPF network segment. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-1/0/1 metric 5 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 


the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface fe-1/0/1.0 { 
metric 5; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 
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Verification 


IN THIS SECTION 


@ = Verifying the Configured Metric | 216 
@ Verifying the Route | 216 


Confirm that the configuration is working properly. 
Verifying the Configured Metric 


Purpose 


Verify the metric setting on the interface. Confirm that the Cost field displays the interface’s configured 
metric (cost). When choosing paths to a destination, OSPF uses the path with the lowest cost. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Verifying the Route 


Purpose 


When choosing paths to a destination, OSPF uses the path with the lowest total cost. Confirm that OSPF 
is using the appropriate path. 


Action 


From operational mode, enter the show route command. 


SEE ALSO 


Understanding OSPF Traffic Control | 209 
Example: Controlling OSPF Route Preferences | 220 
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Example: Dynamically Adjusting OSPF Interface Metrics Based on 
Bandwidth 
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This example shows how to dynamically adjust OSPF interface metrics based on bandwidth. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Overview 


You can specify a set of bandwidth threshold values and associated metric values for an OSPF interface. 
When the bandwidth of an interface changes, Junos OS automatically sets the interface metric to the 
value associated with the appropriate bandwidth threshold value. When you configure bandwidth-based 
metric values, you typically configure multiple bandwidth and metric values. 


In this example, you configure OSPF interface aeO for bandwidth-based metrics by including the 
bandwidth-based-metrics statement and the following settings: 


e bandwidth—Specifies the bandwidth threshold in bits per second. The range is 9600 through 
1,000,000,000,000,000. 
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e metric—Specifies the metric value to associate with a specific bandwidth value. The range is 1 through 
65,535. 


Configuration 


CLI Quick Configuration 

To quickly configure bandwidth threshold values and associated metric values for an OSPF interface, copy 
the following commands, paste them into a text file, remove any line breaks, change any details necessary 
to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy 
level, and then enter commit from configuration mode. 


[edit] 

set protocols ospf area 0.0.0.0 interface ae0.0 metric 5 

set protocols ospf area 0.0.0.0 interface ae0.0 bandwidth-based-metrics bandwidth 1g metric 60 
set protocols ospf area 0.0.0.0 interface ae0.0 bandwidth-based-metrics bandwidth 10g metric 50 


To configure the metric for a specific OSPF interface: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Configure the metric of the OSPF network segment. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface aeO metric 5 


3. Configure the bandwidth threshold values and associated metric values. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface ae0.0 bandwidth-based-metrics bandwidth 1g metric 60 
user@host# set interface ae0.0 bandwidth-based-metrics bandwidth 10g metric 50 


4. If you are done configuring the device, commit the configuration. 
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[edit protocols ospf area 0.0.0.0 ] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface ae0.0 { 
bandwidth-based-metrics { 
bandwidth 1g metric 60; 
bandwidth 10g metric 50; 
} 


metric 5; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Configured Metric 


Purpose 


Verify the metric setting on the interface. Confirm that the Cost field displays the interface’s configured 
metric (cost). When choosing paths to a destination, OSPF uses the path with the lowest cost. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 
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| Example: Controlling OSPF Route Preferences 
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This example shows how to control OSPF route selection in the forwarding table. This example also shows 
how you might control route selection if you are migrating from OSPF to another IGP. 


Requirements 


This example assumes that OSPF is properly configured and running in your network, and you want to 
control route selection because you are planning to migrate from OSPF to a different IGP. 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the IGP that you want to migrate to. 


Overview 
Route preferences are used to select which route is installed in the forwarding table when several protocols 


calculate routes to the same destination. The route with the lowest preference value is selected. 


By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a preference 
value of 150. You might want to modify this setting if you are planning to migrate from OSPF to a different 
IGP. Modifying the route preferences enables you to perform the migration in a controlled manner. 


This example makes the following assumptions: 


e OSPF is already running in your network. 
e You want to migrate from OSPF to IS-IS. 


e You configured IS-IS per your network requirements and confirmed it is working properly. 
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In this example, you increase the OSPF route preference values to make them less preferred than IS-IS 
routes by specifying 168 for internal OSPF routes and 169 for external OSPF routes. IS-IS internal routes 
have a preference of either 15 (for Level1) or 18 (for Level 2), and external routes have a preference of 
160 (for Level 1) or 165 (for Level 2). In general, it is preferred to leave the new protocol at its default 
settings to minimize complexities and simplify any future addition of routing devices to the network. To 
modify the OSPF route preference values, configure the following settings: 


e preference—Specifies the route preference for internal OSPF routes. By default, internal OSPF routes 
have a value of 10. The range is from 0 through 4,294967,295 (2° - 1). 


e external-preference—Specifies the route preference for external OSPF routes. By default, external OSPF 
routes have a value of 150. The range is from O through 4,294967,295 (ao - 1). 


Configuration 


CLI Quick Configuration 


To quickly configure the OSPF route preference values, copy the following commands, paste them into a 
text file, remove any line breaks, change any details necessary to match your network configuration, copy 
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 


[edit] 
set protocols ospf preference 168 external-preference 169 


To configure route selection: 


1. Enter OSPF configuration mode and set the external and internal routing preferences. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf preference 168 external-preference 169 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 
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Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
preference 168; 
external-preference 169; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 


@ Verifying the Route | 222 


Confirm that the configuration is working properly. 


Verifying the Route 


Purpose 


Verify that the IGP is using the appropriate route. After the new IGP becomes the preferred protocol (in 
this example, IS-IS), you should monitor the network for any issues. After you confirm that the new IGP 
is working properly, you can remove the OSPF configuration from the routing device by entering the delete 
ospf command at the [edit protocols] hierarchy level. 


Action 


From operational mode, enter the show route command. 


Understanding OSPF Overload Function 


If the time elapsed after the OSPF instance is enabled is less than the specified timeout, overload mode 
is set. 
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You can configure the local routing device so that it appears to be overloaded. An overloaded routing 
device determines it is unable to handle any more OSPF transit traffic, which results in sending OSPF 
transit traffic to other routing devices. OSPF traffic to directly attached interfaces continues to reach the 
routing device. You might configure overload mode for many reasons, including: 


e If you want the routing device to participate in OSPF routing, but do not want it to be used for transit 
traffic. This could include a routing device that is connected to the network for analysis purposes, but 
is not considered part of the production network, such as network management routing devices. 


e If you are performing maintenance on a routing device in a production network. You can move traffic 
off that routing device so network services are not interrupted during your maintenance window. 


You configure or disable overload mode in OSPF with or without a timeout. Without a timeout, overload 
mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the 
time elapsed since the OSPF instance started is less than the specified timeout. 


A timer is started for the difference between the timeout and the time elapsed since the instance started. 
When the timer expires, overload mode is cleared. In overload mode, the router link-state advertisement 
(LSA) is originated with all the transit router links (except stub) set to a metric of OxXFFFF. The stub router 
links are advertised with the actual cost of the interfaces corresponding to the stub. This causes the transit 
traffic to avoid the overloaded routing device and to take paths around the routing device. However, the 
overloaded routing device's own links are still accessible. 


The routing device can also dynamically enter the overload state, regardless of configuring the device to 
appear overloaded. For example, if the routing device exceeds the configured OSPF prefix limit, the routing 
device purges the external prefixes and enters into an overload state. 


In cases of incorrect configurations, the huge number of routes might enter OSPF, which can hamper the 
network performance. To prevent this, prefix-export-limit should be configured which will purge externals 
and prevent the network from the bad impact. 


By allowing any number of routes to be exported into OSPF, the routing device can become overwhelmed 
and potentially flood an excessive number of routes into an area. You can limit the number of routes 
exported into OSPF to minimize the load on the routing device and prevent this potential problem. 


By default, there is no limit to the number of prefixes (routes) that can be exported into OSPF. To prevent 
this, prefix-export-limit should be configured which will purge externals and prevent the network. 


Starting from Junos OS Release 18.2 onward, the following functionalities are supported by Stub Router 
in your OSPF network, when the OSPF is overloaded: 


e Allow Route leaking—external prefixes are redistributed during OSPF overload and the prefixes are 
originated with normal cost. 


e Advertise stub network with max metric—stub networks are advertised with maximum metric during 
OSPF overload. 
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e Advertise intra-area prefix with max metric—intra-area prefixes are advertised with maximum metric 
during OSPF overload. 


e Advertise external prefix with max possible metric—OSPF AS external prefixes are redistributed during 
OSPF overload and the prefixes are advertised with maximum cost. 


You can now configure the following when OSPF is overloaded: 


e allow-route-leaking at the [edit protocols <ospf | ospf3> overload] hierarchy level to advertise the 
external prefixes with normal cost. 


e stub-network at the [edit protocols ospf overload] hierarchy level to advertise stub network with 
maximum metric. 


intra-area-prefix at the [edit protocols ospf3 overload] hierarchy level to advertise intra-area prefix with 
maximum metric. 


as-external at the [edit protocols <ospf | ospf3> overload] hierarchy level to advertise external prefix 
with maximum metric. 


To limit the number of prefixes exported to OSPF: 


[edit] 
set protocols ospf prefix-export-limit number 


The prefix export limit number can be a value from O through 4,294,967,295. 


SEE ALSO 


overload | 712 
allow-route-leaking | 608 
stub-network | 754 


intra-area-prefix | 670 





as-external | 613 


| Example: Configuring OSPF to Make Routing Devices Appear Overloaded 
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@ = Configuration | 226 
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This example shows how to configure a routing device running OSPF to appear to be overloaded. 


Requirements 


Before you begin: 


Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


You can configure a local routing device running OSPF to appear to be overloaded, which allows the local 
routing device to participate in OSPF routing, but not for transit traffic. When configured, the transit 
interface metrics are set to the maximum value of 65535. 


This example includes the following settings: 


e overload—Configures the local routing device so it appears to be overloaded. You might configure this 
if you want the routing device to participate in OSPF routing, but do not want it to be used for transit 
traffic, or you are performing maintenance on a routing device in a production network. 


e timeout seconds—(Optional) Specifies the number of seconds at which the overload is reset. If no timeout 
interval is specified, the routing device remains in the overload state until the overload statement is 
deleted or a timeout is set. In this example, you configure 60 seconds as the amount of time the routing 
device remains in the overload state. By default, the timeout interval is O seconds (this value is not 
configured). The range is from 60 through 1800 seconds. 
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Configuration 


CLI Quick Configuration 


To quickly configure a local routing device to appear as overloaded, copy the following commands, paste 
them into a text file, remove any line breaks, change any details necessary to match your network 
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter 
commit from configuration mode. 


[edit] 
set protocols ospf overload timeout 60 


Step-by-Step Procedure 


To configure a local routing device to appear overloaded: 


1. Enter OSPF configuration mode. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf 


2. Configure the local routing device to be overloaded. 


[edit protocols ospf] 
user@host# set overload 


3. (Optional) Configure the number of seconds at which overload is reset. 


[edit protocols ospf] 
user@host# set overload timeout 60 


4. (Optional) Configure the limit on the number prefixes exported to OSPF, to minimise the load on the 
routing device and prevent the device from entering the overload mode. 


[edit protocols ospf] 
user@host# set prefix-export-limit 50 
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5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf] 
user@host# commit 


Results 

Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. The output 
includes the optional timeout and prefix-export-limit statements. 


user@host# show protocols ospf 


prefix—export-limit 50; 


overload timeout 60; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 
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Verifying the Viable Next Hop | 228 


Confirm that the configuration is working properly. 


Verifying Traffic Has Moved Off Devices 


Purpose 
Verify that the traffic has moved off the upstream devices. 


Action 
From operational mode, enter the show interfaces detail command. 


Verifying Transit Interface Metrics 


Purpose 
Verify that the transit interface metrics are set to the maximum value of 65535 on the downstream 
neighboring device. 


Action 


From operational mode, enter the show ospf database router detail advertising-router address command 
for OSPFv2, and enter the show ospf3 database router detail advertising-router address command for 
OSPFv3. 


Verifying the Overload Configuration 


Purpose 


Verify that overload is configured by reviewing the Configured overload field. If the overload timer is also 
configured, this field also displays the time that remains before it is set to expire. 


Action 


From operational mode, enter the show ospf overview command for OSPFv2, and the show ospf3 overview 
command for OSPFv3. 


Verifying the Viable Next Hop 


Purpose 


Verify the viable next hop configuration on the upstream neighboring device. If the neighboring device is 
overloaded, it is not used for transit traffic and is not displayed in the output. 


Action 


From operational mode, enter the show route address command. 


Understanding the SPF Algorithm Options for OSPF 


OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine 
the route to reach each destination. The SPF algorithm describes how OSPF determines the route to reach 
each destination, and the SPF options control the timers that dictate when the SPF algorithm runs. 
Depending on your network environment and requirements, you might want to modify the SPF options. 
For example, consider a large-scale environment with a large number of devices flooding link-state 
advertisements (LSAs) through out the area. In this environment, it is possible to receive a large number 
of LSAs to process, which can consume memory resources. By configuring the SPF options, you continue 
to adapt to the changing network topology, but you can minimize the amount of memory resources being 
used by the devices to run the SPF algorithm. 
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You can configure the following SPF options: 
e The delay in the time between the detection of a topology change and when the SPF algorithm actually 
runs. 


e The maximum number of times that the SPF algorithm can run in succession before the hold-down timer 
begins. 


e The time to hold down, or wait, before running another SPF calculation after the SPF algorithm has run 
in succession the configured number of times. If the network stabilizes during the holddown period and 
the SPF algorithm does not need to run again, the system reverts to the configured values for the delay 
and rapid-runs statements. 


Example: Configuring SPF Algorithm Options for OSPF 
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This example shows how to configure the SPF algorithm options. The SPF options control the timers that 
dictate when the SPF algorithm runs. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 
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Overview 


OSPF uses the SPF algorithm to determine the route to reach each destination. All routing devices in an 
area run this algorithm in parallel, storing the results in their individual topology databases. Routing devices 
with interfaces to multiple areas run multiple copies of the algorithm. The SPF options control the timers 
used by the SPF algorithm. 


Before you modify any of the default settings, you should have a good understanding of your network 
environment and requirements. 


This example shows how to configure the options for running the SPF algorithm. You include the spf-options 
statement and the following options: 


e delay—Configures the amount of time (in milliseconds) between the detection of a topology and when 
the SPF actually runs. When you modify the delay timer, consider your requirements for network 
reconvergence. For example, you want to specify a timer value that can help you identify abnormalities 
in the network, but allow a stable network to reconverge quickly. By default, the SPF algorithm runs 
200 milliseconds after the detection of a topology. The range is from 50 through 8000 milliseconds. 


rapid-runs—Configures the maximum number of times that the SPF algorithm can run in succession 


before the hold-down timer begins. By default, the number of SPF calculations that can occur in succession 
is 3. The range is from 1 through 10. Each SPF algorithm is run after the configured SPF delay. When 
the maximum number of SPF calculations occurs, the hold-down timer begins. Any subsequent SPF 
calculation is not run until the hold-down timer expires. 


holddown—Configures the time to hold down, or wait, before running another SPF calculation after the 
SPF algorithm has run in succession the configured maximum number of times. By default, the hold 
down time is 5000 milliseconds. The range is from 2000 through 20,000 milliseconds. If the network 
stabilizes during the holddown period and the SPF algorithm does not need to run again, the system 
reverts to the configured values for the delay and rapid-runs statements. 


Configuration 


CLI Quick Configuration 
To quickly configure the SPF options, copy the following commands and paste them into the CLI. 


[edit] 

set protocols ospf spf-options delay 210 

set protocols ospf spf-options rapid-runs 4 
set protocols ospf spf-options holddown 5050 


Step-by-Step Procedure 
To configure the SPF options: 


1. Enter OSPF configuration mode. 
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NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf 


2. Configure the SPF delay time. 


[edit protocols ospf] 
user@host# set spf-options delay 210 


3. Configure the maximum number of times that the SPF algorithm can run in succession. 


[edit protocols ospf] 
user@host# set spf-options rapid-runs 4 


4. Configure the SPF hold-down timer. 


[edit protocols ospf] 
user@host# set spf-options holddown 5050 


5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
spf-options { 

delay 210; 

holddown 5050; 

rapid-runs 4; 
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To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 
Verifying SPF Options 


Purpose 


Verify that SPF is operating per your network requirements. Review the SPF delay field, the SPF holddown 
field, and the SPF rapid runs fields. 


Action 


From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 


Configuring OSPF Refresh and Flooding Reduction in Stable Topologies 


The OSPF standard requires that every link-state advertisement (LSA) be refreshed every 30 minutes. The 
Juniper Networks implementation refreshes LSAs every 50 minutes. By default, any LSA that is not refreshed 
expires after 60 minutes. This requirement can result in traffic overhead that makes it difficult to scale 
OSPF networks. You can override the default behavior by specifying that the DoNotAge bit be set in 
self-originated LSAs when they are initially sent by the router or switch. Any LSA with the DoNotAge bit 
set is reflooded only when a change occurs in the LSA. This feature thus reduces protocol traffic overhead 
while permitting any changed LSAs to be flooded immediately. Routers or switches enabled for flood 
reduction continue to send hello packets to their neighbors and to age self-originated LSAs in their databases. 


The Juniper implementation of OSPF refresh and flooding reduction is based on RFC 4136, OSPF Refresh 
and Flooding Reduction in Stable Topologies. However, the Juniper implementation does not include the 
forced-flooding interval defined in the RFC. Not implementing the forced-flooding interval ensures that 
LSAs with the DoNotAge bit set are reflooded only when a change occurs. 


This feature is supported for the following: 


e OSPFv2 and OSPF v3 interfaces 
e OSPFv3 realms 

e OSPFv2 and OSPF v3 virtual links 
e OSPFv2 sham links 
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e OSPF v2 peer interfaces 
e All routing instances supported by OSPF 


e Logical systems 


To configure flooding reduction for an OSPF interface, include the flood-reduction statement at the [edit 
protocols (ospf | ospf3) area area-id interface interface-id] hierarchy level. 


NOTE: If you configure flooding reduction for an interface configured as a demand circuit, the 
LSAs are not initially flooded, but sent only when their content has changed. Hello packets and 
LSAs are sent and received on a demand-circuit interface only when a change occurs in the 
network topology. 


In the following example, the OSPF interface so-0/0/1.0 is configured for flooding reduction. As a result, 
all the LSAs generated by the routes that traverse the specified interface have the DoNotAge bit set when 
they are initially flooded, and LSAs are refreshed only when a change occurs. 


[edit] 
protocols ospf { 
area 0.0.0.0 { 
interface so-0/0/1.0 { 
flood-reduction; 


} 


interface 100.0; 
interface so-0/0/0.0; 


NOTE: Beginning with Junos OS Release 12.2, you can configure a global default link-state 
advertisement (LSA) flooding interval in OSPF for self-generated LSAs by including the 
Isa-refresh-interval minutes statement at the [edit protocols (ospf | ospf3)] hierarchy level. The 
Juniper Networks implementation refreshes LSAs every 50 minutes. The range is 25 through 
50 minutes. By default, any LSA that is not refreshed expires after 60 minutes. 


If you have both the global LSA refresh interval configured for OSPF and OSPF flooding reduction 
configured for a specific interface in an OSPF area, the OSPF flood reduction configuration takes 
precedence for that specific interface. 


234 
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flood-reduction | 646 
Isa-refresh-interval | 678 


| Understanding Synchronization Between LDP and IGPs 


LDP is a protocol for distributing labels in non-traffic-engineered applications. Labels are distributed along 
the best path determined by the interior gateway protocol (IGP). If synchronization between LDP and the 
IGP is not maintained, the label-switch path (LSP) goes down. When LDP is not fully operational on a given 
link (a session is not established and labels are not exchanged), the IGP advertises the link with the maximum 
cost metric. The link is not preferred but remains in the network topology. 


LDP synchronization is supported only on active point-to-point interfaces and LAN interfaces configured 
as point-to-point under the IGP. LDP synchronization is not supported during graceful restart. 


SEE ALSO 


Example: Configuring Synchronization Between LDP and OSPF | 234 


For more information about LDP, see LDP Overview and LDP Configuration Guidelines in the MPLS 
Applications User Guide 


| Example: Configuring Synchronization Between LDP and OSPF 


IN THIS SECTION 


Requirements | 235 
Overview | 235 
Configuration | 235 


Verification | 238 


This example shows how to configure synchronization between LDP and OSPFv2. 


235 


Requirements 


Before you begin: 


Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 


Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


In this example, configure synchronization between LDP and OSPF v2 by performing the following tasks: 


Enable LDP on interface so-1/0/3, which is a member of OSPF area 0.0.0.0, by including the Idp statement 
at the [edit protocols] hierarchy level. You can configure one or more interfaces. By default, LDP is 


disabled on the routing device. 


Enable LDP synchronization by including the Idp-synchronization statement at the [edit protocols ospf 
area area-id interface interface-name] hierarchy level. This statement enables LDP synchronization by 


advertising the maximum cost metric until LDP is operational on the link. 


Configure the amount of time (in seconds) the routing device advertises the maximum cost metric for a 
link that is not fully operational by including the hold-time statement at the [edit protocols ospf area 
area-id interface interface-name Idp-synchronization] hierarchy level. If you do not configure the 
hold-time statement, the hold-time value defaults to infinity. The range is from 1 through 65,535 seconds. 
In this example, configure 10 seconds for the hold-time interval. 


This example also shows how to disable synchronization between LDP and OSPF v2 by including the disable 
statement at the [edit protocols ospf area area-id interface interface-name Idp-synchronization] hierarchy 
level. 


Configuration 


IN THIS SECTION 


@ Enabling Synchronization Between LDP and OSPFv2 | 236 
@ Disabling Synchronization Between LDP and OSPFv2 | 237 
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Enabling Synchronization Between LDP and OSPFv2 


CLI Quick Configuration 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide. 


To quickly enable synchronization between LDP and OSPF v2, copy the following commands, remove any 


line breaks, and then paste them into the CLI. 


[edit] 
set protocols Idp interface so-1/0/3 
set protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-syncrhonization hold-time 10 


Step-by-Step Procedure 
To enable synchronization between LDP and OSPFv2: 


1. Enable LDP on the interface. 


[edit] 
user@host# set protocols Idp interface so-1/0/3 


2. Configure LDP synchronization and optionally configure a time period of 10 seconds to advertise the 
maximum cost metric for a link that is not fully operational. 


[edit ] 
user@host# edit protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-synchronization 


3. Configure a time period of 10 seconds to advertise the maximum cost metric for a link that is not fully 
operational. 


[edit protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-synchronization ] 
user@host# set hold-time 10 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-synchronization] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols Idp and show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show protocols Idp 
interface so-1/0/3.0; 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface so-1/0/3.0 { 
Idp-synchronization { 
hold-time 10; 


Disabling Synchronization Between LDP and OSPFv2 


CLI Quick Configuration 


To quickly disable synchronization between LDP and OSPF v2, copy the following command and paste it 
into the CLI. 


[edit] 
set protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-synchronization disable 


Step-by-Step Procedure 
To disable synchronization between LDP and OSPF: 


1. Disable synchronization by including the disable statement. 

[edit ] 

user@host# set protocols ospf area 0.0.0.0 interface so-1/0/3 Idp-synchronization disable 
2. If you are done configuring the device, commit the configuration. 

[edit] 


user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 
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user@host# show protocols ospf 
area 0.0.0.0 { 
interface so-1/0/3.0 { 
Idp-synchronization { 
disable; 


Verification 


Confirm that the configuration is working properly. 


Verifying the LDP Synchronization State of the Interface 


Purpose 


Verify the current state of LDP synchronization on the interface. The LDP sync state displays information 
related to the current state, and the config holdtime field displays the configured hold-time interval. 


Action 


From operational mode, enter the show ospf interface extensive command. 


OSPFv2 Compatibility with RFC 1583 Overview 


By default, the Junos OS implementation of OSPFv2 is compatible with RFC 1583, OSPF Version 2. This 
means that Junos OS maintains a single best route to an autonomous system (AS) boundary router in the 
OSPF routing table, rather than multiple intra-AS paths, if they are available. You can now disable 
compatibility with RFC 1583. It is preferable to do so when the same external destination is advertised by 
AS boundary routers that belong to different OSPF areas. When you disable compatibility with RFC 1583, 
the OSPF routing table maintains the multiple intra-AS paths that are available, which the router uses to 
calculate AS external routes as defined in RFC 2328, OSPF Version 2. Being able to use multiple available 
paths to calculate an AS external route can prevent routing loops. 


SEE ALSO 


Example: Disabling OSPFv2 Compatibility with RFC 1583 | 239 
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| Example: Disabling OSPFv2 Compatibility with RFC 1583 


IN THIS SECTION 


Requirements | 239 
Overview | 239 
Configuration | 239 


Verification | 240 


This example shows how to disable OSPFv2 compatibility with RFC 1583 on the routing device. 


Requirements 


No special configuration beyond device initialization is required before disabling OSPFv2 compatibility 
with RFC 1583. 


Overview 


By default, the Junos OS implementation of OSPF is compatible with RFC 1583. This means that Junos 
OS maintains a single best route to an autonomous system (AS) boundary router in the OSPF routing table, 
rather than multiple intra-AS paths, if they are available. You can disable compatibility with RFC 1583. It 
is preferable to do so when the same external destination is advertised by AS boundary routers that belong 
to different OSPF areas. When you disable compatibility with RFC 1583, the OSPF routing table maintains 
the multiple intra-AS paths that are available, which the router uses to calculate AS external routes as 
defined in RFC 2328. Being able to use multiple available paths to calculate an AS external route can 
prevent routing loops. To minimize the potential for routing loops, configure the same RFC compatibility 
on all OSPF devices in an OSPF domain. 


Configuration 


CLI Quick Configuration 

To quickly disable OSPFv2 compatibility with RFC 1583, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. You configure this setting on all devices that are part of the OSPF domain. 


[edit] 
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set protocols ospf no-rfc-1583 


Step-by-Step Procedure 
To disable OSPFv2 compatibility with RFC 1583: 


1. Disable RFC 1583. 


[edit] 
user@host# set protocols ospf no-rfc-1583 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


NOTE: Repeat this configuration on each routing device that participates in an OSPF routing 
domain. 


Results 
Confirm your configuration by entering the show protocols ospf command. If the output does not display 


the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
no-rfc-1583; 


Verification 


Confirm that the configuration is working properly. 
Verifying the OSPF Routes 


Purpose 


Verify that the OSPF routing table maintains the intra-AS paths with the largest metric, which the router 
uses to calculate AS external routes. 


Action 


From operational mode, enter the show ospf route detail command. 
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Configuring OSPF Authentication 
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IP Security (IPsec) provides a secure way to authenticate senders and encrypt IP version 4 (IPv4) traffic 
between network devices. IPsec offers network administrators for Juniper Networks EX Series Ethernet 
Switches and their users the benefits of data confidentiality, data integrity, sender authentication, and 
anti-replay services. 


IPsec is a framework for ensuring secure private communication over IP networks and is based on standards 
developed by the International Engineering Task Force (IETF). IPsec provides security services at the 
network layer of the Open Systems Interconnection (OSI) model by enabling a system to select required 
security protocols, determine the algorithms to use for the security services, and implement any 
cryptographic keys required to provide the requested services. You can use IPsec to protect one or more 
paths between a pair of hosts, between a pair of security gateways (such as switches), or between a security 
gateway and a host. 


OSPF version 3 (OSPFv3), unlike OSPF version 2 (OSPFv2), does not have a built-in authentication method 
and relies on IPsec to provide this functionality. You can secure specific OSPFv3 interfaces and protect 
OSPFv3 virtual links. 


Authentication Algorithms 


Authentication is the process of verifying the identity of the sender. Authentication algorithms use a shared 
key to verify the authenticity of the IPsec devices. The Juniper Networks Junos operating system (Junos 
OS) uses the following authentication algorithms: 


e Message Digest 5 (MD5) uses a one-way hash function to convert a message of arbitrary length to a 
fixed-length message digest of 128 bits. Because of the conversion process, it is mathematically infeasible 
to calculate the original message by computing it backwards from the resulting message digest. Likewise, 
a change to a single character in the message will cause it to generate a very different message digest 
number. 


To verify that the message has not been tampered with, Junos OS compares the calculated message 
digest against a message digest that is decrypted with a shared key. Junos OS uses the MD5 hashed 
message authentication code (HMAC) variant that provides an additional level of hashing. MD5 can be 
used with an authentication header (AH) and Encapsulating Security Payload (ESP). 


Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm than MD5. SHA-1 takes a message of less 
than 264 bits in length and produces a 160-bit message digest. The large message digest ensures that 

the data has not been changed and that it originates from the correct source. Junos OS uses the SHA-1 
HMAC variant that provides an additional level of hashing. SHA-1 can be used with AH, ESP, and Internet 
Key Exchange (IKE). 
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Encryption Algorithms 


Encryption encodes data into a secure format so that it cannot be deciphered by unauthorized users. As 
with authentication algorithms, a shared key is used with encryption algorithms to verify the authenticity 
of IPsec devices. Junos OS uses the following encryption algorithms: 


Data Encryption Standard cipher-block chaining (DES-CBC) is a symmetric secret-key block algorithm. 


DES uses a key size of 64 bits, where 8 bits are used for error detection and the remaining 56 bits provide 
encryption. DES performs a series of simple logical operations on the shared key, including permutations 
and substitutions. CBC takes the first block of 64 bits of output from DES, combines this block with the 
second block, feeds this back into the DES algorithm, and repeats this process for all subsequent blocks. 


Triple DES-CBC (3DES-CBC) is an encryption algorithm that is similar to DES-CBC but provides a much 
stronger encryption result because it uses three keys for 168-bit (3 x 56-bit) encryption. 3DES works 
by using the first key to encrypt the blocks, the second key to decrypt the blocks, and the third key to 
reencrypt the blocks. 


IPsec Protocols 


IPsec protocols determine the type of authentication and encryption applied to packets that are secured 
by the switch. Junos OS supports the following IPsec protocols: 


e AH—Defined in RFC 2402, AH provides connectionless integrity and data origin authentication for IPv4. 
It also provides protection against replays. AH authenticates as much of the IP header as possible, as 
well as the upper-level protocol data. However, some IP header fields might change in transit. Because 
the value of these fields might not be predictable by the sender, they cannot be protected by AH. In an 
IP header, AH can be identified with a value of 51 in the Protocol field of an IPv4 packet. 


e ESP—Defined in RFC 2406, ESP can provide encryption and limited traffic flow confidentiality or 
connectionless integrity, data origin authentication, and an anti-replay service. In an IP header, ESP can 
be identified with a value of 50 in the Protocol field of an IPv4 packet. 


Security Associations 


An IPsec consideration is the type of security association (SA) that you wish to implement. An SA is a set 
of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. 
These specifications include preferences for the type of authentication, encryption, and IPsec protocol to 
be used when establishing the IPsec connection. An SA can be either unidirectional or bidirectional, 
depending on the choices made by the network administrator. An SA is uniquely identified by a Security 
Parameter Index (SPI), an IPv4 or IPv6 destination address, and a security protocol (AH or ESP) identifier. 


IPsec Modes 


Junos OS supports the following IPsec modes: 
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e Tunnel mode is supported for both AH and ESP in Junos OS. In tunnel mode, the SA and associated 
protocols are applied to tunneled IPv4 or IPv6é packets. For a tunnel mode SA, an outer IP header specifies 
the IPsec processing destination and an inner IP header specifies the ultimate destination for the packet. 
The security protocol header appears after the outer IP header and before the inner IP header. In addition, 
there are slight differences for tunnel mode when you implement it with AH and ESP: 


e For AH, portions of the outer IP header are protected, as well as the entire tunneled IP packet. 


e For ESP, only the tunneled packet is protected, not the outer header. 


When one side of an SA is a security gateway (such as a switch), the SA must use tunnel mode. However, 
when traffic (for example, SNMP commands or BGP sessions) is destined for a switch, the system acts 
as a host. Transport mode is allowed in this case because the system does not act as a security gateway 
and does not send or receive transit traffic. 


NOTE: Tunnel mode is not supported for OSPF v3 control packet authentication. 


Transport mode provides an SA between two hosts. In transport mode, the protocols provide protection 


primarily for upper-layer protocols. A transport mode security protocol header appears immediately 
after the IP header and any options and before any higher-layer protocols (for example, TCP or UDP). 
There are slight differences for transport mode when you implement it with AH and ESP: 


e For AH, selected portions of the IP header are protected, as well as selected portions of the extension 
headers and selected options within the IPv4 header. 


e For ESP, only the higher-layer protocols are protected, not the IP header or any extension headers 
preceding the ESP header. 


Understanding OSPFv2 Authentication 


All OSPFv2 protocol exchanges can be authenticated to guarantee that only trusted routing devices 
participate in the autonomous system’s routing. By default, OSPFv2 authentication is disabled. 


NOTE: OSPFv3 does not have a built-in authentication method and relies on IP Security (IPsec) 
to provide this functionality. 


You can enable the following authentication types: 


e Simple authentication—Authenticates by using a plain-text password that is included in the transmitted 
packet. The receiving routing device uses an authentication key (password) to verify the packet. 
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e MD5 authentication—Authenticates by using an encoded MD5 checksum that is included in the 
transmitted packet. The receiving routing device uses an authentication key (password) to verify the 
packet. 


You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts 
routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing 
device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that 
interface. 


IPsec authentication (beginning with Junos OS Release 8.3)—Authenticates OSPFv2 interfaces, the 


remote endpoint of a sham link, and the OSPF v2 virtual link by using manual security associations (SAs) 
to ensure that a packet’s contents are secure between the routing devices. You configure the actual 
IPsec authentication separately. 


NOTE: You can configure IPsec authentication together with either MD5 or simple 
authentication. 


The following restrictions apply to IPsec authentication for OSPFv2: 


e Dynamic Internet Key Exchange (IKE) SAs are not supported. 
e Only IPsec transport mode is supported. Tunnel mode is not supported. 


e Because only bidirectional manual SAs are supported, all OSPFv2 peers must be configured with the 
same |Psec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level. 


e You must configure the same IPsec SA for all virtual links with the same remote endpoint address, for 
all neighbors on OSPF nonbroadcast multiaccess (NBMA) or point-to-multipoint links, and for every 
subnet that is part of a broadcast link. 


e OSPFv2 peer interfaces are not supported. 


Because OSPF performs authentication at the area level, all routing devices within the area must have the 
same authentication and corresponding password (key) configured. For MD5 authentication to work, both 
the receiving and transmitting routing devices must have the same MD5 key. In addition, a simple password 
and MD5 key are mutually exclusive. You can configure only one simple password, but multiple MD5 keys. 


As part of your security measures, you can change MD5 keys. You can do this by configuring multiple 
MD5 keys, each with a unique key ID, and setting the date and time to switch to the new key. Each unique 
MD5 key has a unique ID. The ID is used by the receiver of the OSPF packet to determine which key to 
use for authentication. The key ID, which is required for MD5 authentication, specifies the identifier 
associated with the MD5 key. 


SEE ALSO 
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| Overview of IPsec 


| Understanding OSPFv3 Authentication 


OSPF v3 does not have a built-in authentication method and relies on the IP Security (IPsec) suite to provide 
this functionality. IPsec provides such functionality as authentication of origin, data integrity, confidentiality, 
replay protection, and nonrepudiation of source. You can use IPsec to secure specific OSPFv3 interfaces 
and protect OSPFv8 virtual links. 


NOTE: 


You configure the actual IPsec authentication separately from your OSPFv3 configuration and 
then apply IPsec to the OSPFv3 interfaces or OSPFv3 virtual links. 


OSPF v3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP) portions 
of the IPsec Protocol to authenticate routing information between peers. AH can provide connectionless 
integrity and data origin authentication. It also provides protection against replays. AH authenticates as 
much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields 
might change in transit. Because the value of these fields might not be predictable by the sender, they 
cannot be protected by AH. ESP can provide encryption and limited traffic flow confidentiality or 
connectionless integrity, data origin authentication, and an anti-replay service. 


IPsec is based on security associations (SAs). An SA is a set of IPsec specifications that are negotiated 
between devices that are establishing an IPsec relationship. This simplex connection provides security 
services to the packets carried by the SA. These specifications include preferences for the type of 
authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An SA 
is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bidirectional 
traffic, the flows are secured by a pair of SAs. An SA to be used with OSPFv3 must be configured manually 
and use transport mode. Static values must be configured on both ends of the SA. 


Manual SAs require no negotiation between the peers. All values, including the keys, are static and specified 
in the configuration. Manual SAs statically define the security parameter index (SPI) values, algorithms, 
and keys to be used and require matching configurations on both end points (OSPFv3 peers). As a result, 
each peer must have the same configured options for communication to take place. 


The actual choice of encryption and authentication algorithms is left to your IPsec administrator; however, 
we have the following recommendations: 


e Use ESP with NULL encryption to provide authentication to the OSPFv3 protocol headers only. With 
NULL encryption, you are choosing not to provide encryption on OSPFv3 headers. This can be useful 
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for troubleshooting and debugging purposes. For more information about NULL encryption, see RFC 
2410, The NULL Encryption Algorithm and Its Use With IPsec. 


e Use ESP with non-NULL encryption for full confidentiality. With non-NULL encryption, you are choosing 
to provide encryption. For more information about NULL encryption, see RFC 2410, The NULL Encryption 
Algorithm and Its Use With IPsec. 


e Use AH to provide authentication to the OSPFv3 protocol headers, portions of the IPv6 header, and 
portions of the extension headers. 


The following restrictions apply to IPsec authentication for OSPFv3: 


e Dynamic Internet Key Exchange (IKE) security associations (SAs) are not supported. 


e Only IPsec transport mode is supported. In transport mode, only the payload (the data you transfer) of 
the IP packet is encrypted and/or authenticated. Tunnel mode is not supported. 


e Because only bidirectional manual SAs are supported, all OSPFv3 peers must be configured with the 
same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level. 


e You must configure the same IPsec SA for all virtual links with the same remote endpoint address. 


SEE ALSO 


| Overview of IPsec 


| Example: Configuring Simple Authentication for OSPFv2 Exchanges 


IN THIS SECTION 


Requirements | 250 
Overview | 250 
Configuration | 250 


Verification | 252 


This example shows how to enable simple authentication for OSPFv2 exchanges. 
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Requirements 


Before you begin: 
e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices or the 
Junos OS Interfaces Configuration Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


Simple authentication uses a plain-text password that is included in the transmitted packet. The receiving 
routing device uses an authentication key (password) to verify the packet. Plain-text passwords are not 
encrypted and might be subject to packet interception. This method is the least secure and should only 
be used if network security is not your goal. 


You can configure only one simple authentication key (password) on the routing device. The simple key 
can be from 1 through 8 characters and can include ASCII strings. If you include spaces, enclose all characters 
in quotation marks (“ “). 


In this example, you specify OSPFv2 interface so-0/1/0 in area 0.0.0.0, set the authentication type to 
simple-password, and define the key as PssWd4. 


Configuration 


CLI Quick Configuration 


To quickly configure simple authentication, copy the following command, removing any line breaks, and 
then paste the command into the CLI. You must configure all routing devices within the area with the same 
authentication and corresponding password. 


[edit] 
set protocols ospf area 0.0.0.0 interface so-0/1/0 authentication simple-password PssWd4 


Step-by-Step Procedure 


To enable simple authentication for OSPFv2 exchanges: 


1. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Specify the interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# edit interface so-0/1/0 


3. Set the authentication type and the password. 


[edit protocols ospf area 0.0.0.0 interface so-0/1/0.0] 
user@host# set authentication simple-password PssWd4 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 interface so-0/1/0.0] 
user@host# commit 


NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices in the area. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


NOTE: After you configure the password, you do not see the password itself. The output displays 
the encrypted form of the password you configured. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface so-0/1/0.0 { 
authentication { 
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simple-password "$9$-3dY4ZUHm5FevX-db2g"; ## SECRET-DATA 


Verification 


IN THIS SECTION 


@ Verifying the Configured Authentication Method | 252 


Confirm that the configuration is working properly. 


Verifying the Configured Authentication Method 


Purpose 
Verify that the authentication method for sending and receiving OSPF protocol packets is configured. The 
Authentication Type field displays Password when configured for simple authentication. 


Action 
From operational mode, enter the show ospf interface and the show ospf overview commands. 


| Example: Configuring MD5 Authentication for OSPFv2 Exchanges 


IN THIS SECTION 


Requirements | 253 
Overview | 253 
Configuration | 253 


Verification | 255 


This example shows how to enable MD5 authentication for OSPFv2 exchanges. 
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Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices or the 
Junos OS Interfaces Configuration Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. The 
receiving routing device uses an authentication key (password) to verify the packet. 


You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing 
updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only 
accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface. 


In this example, you create the backbone area (area 0.0.0.0), specify OSPFv2 interface so-0/2/0, set the 
authentication type to md5, and then define the authentication key ID as 5 and the password as PssWd8. 


Configuration 


CLI Quick Configuration 


To quickly configure MD5 authentication, copy the following command and paste it into the CLI. 


[edit] 
set protocols ospf area 0.0.0.0 interface so-0/2/0 authentication md5 5 key PssWd8 


Step-by-Step Procedure 
To enable MD5 authentication for OSPFv2 exchanges: 


1. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 
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2. Specify the interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# edit interface so-0/2/0 


3. Configure MD5 authentication and set a key ID and an authentication password. 


[edit protocols ospf area 0.0.0.0 interface sO-0/2/0.0] 
user@host# set authentication md5 5 key PssWd8 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 interface sO-0/2/0.0] 
user@host# commit 


NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


NOTE: After you configure the password, you do not see the password itself. The output displays 
the encrypted form of the password you configured. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface so-0/2/0.0 { 
authentication { 
md5 5 key "$9$pXXhulhreWx-wQF9puBEh"; ## SECRET-DATA 
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Verification 


Confirm that the configuration is working properly. 


Verifying the Configured Authentication Method 


Purpose 


Verify that the authentication method for sending and receiving OSPF protocol packets is configured. 
When configured for MD5 authentication, the Authentication Type field displays MD5, the Active key ID 
field displays the unique number you entered that identifies the MD5 key, and the Start time field displays 
the date as Start time 1970 Jan 01 00:00:00 PST. Do not be alarmed by this start time. This is the default 
start time that the routing device displays if the MD5 key is effective immediately. 


Action 


From operational mode, enter the show ospf interface and the show ospf overview commands. 


Example: Configuring a Transition of MD5 Keys on an OSPF v2 Interface 


IN THIS SECTION 
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Verification | 258 


This example shows how to configure a transition of MD5 keys on an OSPF v2 interface. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices or the 
Junos OS Interfaces Configuration Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. For MD5 
authentication to work, both the receiving and transmitting routing devices must have the same MD5 key. 


You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing 
updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only 
accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface. 


For increased security, you can configure multiple MD5 keys, each with a unique key ID, and set the date 
and time to switch to a new key. The receiver of the OSPF packet uses the ID to determine which key to 
use for authentication. 


In this example, you configure new keys to take effect at 12:01 AM on the first day of the next three 
months on OSPF v2 interface fe-0/0/1 in the backbone area (area 0.0.0.0), and you configure the following 
MD5 authentication settings: 


e md5—Specifies the MD5 authentication key ID. The key ID can be set to any value between O and 255, 
with a default value of 0. The routing device only accepts OSPFv2 packets sent using the same key ID 
that is defined for that interface. 


e key—Specifies the MD5 key. Each key can be a value from 1 through 16 characters long. Characters can 
include ASCII strings. If you include spaces, enclose all characters in quotation marks (““). 


start-time—Specifies the time to start using the MD5 key. This option enables you to configure a smooth 
transition mechanism for multiple keys. The start time is relevant for transmission but not for receiving 
OSPF packets. 


NOTE: You must set the same passwords and transition dates and times on all devices in the 
area so that OSPFv2 adjacencies remain active. 


Configuration 


CLI Quick Configuration 


To quickly configure multiple MD5 keys on an OSPF v2 interface, copy the following commands, remove 
any line breaks, and then paste the commands into the CLI. 
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[edit] 

set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 1 key $2010HaL 

set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 2 key NeWpsswcF EB start-time 
2011-02-01.00:01 

set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 3 key NeWpsswdMAR start-time 
2011-03-01.00:01 

set protocols ospf area 0.0.0.0 interface fe-0/1/0 authentication md5 4 key NeWpsswdAPR start-time 
2011-04-01.00:01 


Step-by-Step Procedure 
To configure multiple MD5 keys on an OSPF v2 interface: 


1. Create an OSPF area. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Specify the interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# edit interface fe-0/1/0 


3. Configure MD5 authentication and set an authentication password and key ID. 


[edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] 
user@host# set authentication md5 1 key $2010HaL 


4. Configure a new key to take effect at 12:01 AM on the first day of February, March, and April. 


You configure a new authentication password and key ID for each month. 


a. For the month of February, enter the following: 


[edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] 
user@host# set authentication md5 2 key NeWpsswaF EB start-time 2011-02-01.00:01 


b. For the month of March, enter the following: 


[edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] 
user@host# set authentication md5 3 key NeWpsswdMaAk start-time 2011-03-01.00:01 
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c. For the month of April, enter the following: 


[edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] 
user@host# set authentication md5 4 key NeWpsswdAPR start-time 2011-04-01.00:01 


5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 interface fe-0/1/0.0] 
user@host# commit 


NOTE: Repeat this entire configuration on all peer OSPFv2 routing devices. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


NOTE: After you configure the password, you do not see the password itself. The output displays 
the encrypted form of the password you configured. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/1/0.0 { 
authentication { 
md5 1 key "$9$wzs24JGDjk.2gfT Q3CApOB1hy"; ## SECRET-DATA 
md5 2 key "$9$Q9gz39t1IcML7EcwgJZq.RhSyIMN-b40ZDi" start-time "2011-2-1.00:01:00 -0800"; ## 
SECRET-DATA 
md5 3 key "$9$zjo2nCpIRSWXNhSs4ZG.mEcyreW2gaZGjCt" start-time "2011-3-1.00:01:00 -O800"; ## 
SECRET-DATA 
md5 4 key "$9$fQn90OReML1Rds40iHBIEhSevMLXNVqm'" start-time "2011-4-1.00:01:00 -0700"; ## 
SECRET-DATA 


Verification 


Confirm that the configuration is working properly. 
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Verifying the Configured Authentication Method 


Purpose 


Verify that the authentication method for sending and receiving OSPF protocol packets is configured. 
When configured for MD5 authentication with a transition of keys, the Auth type field displays MD5, the 
Active key ID field displays the unique number you entered that identifies the MD5 key, and the Start 
time field displays the time at which the routing device starts using an MD5 key to authenticate OSPF 
packets transmitted on the interface you configured. 


Action 


From operational mode, enter the show ospf interface and the show ospf overview commands. 


Using IPsec to Secure OSPFv3 Networks (CLI Procedure) 
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OSPF version 3 (OSPFv3) does not have a built-in authentication method and relies on IP Security (IPsec) 
to provide this functionality. You can use IPsec to secure OSPF v3 interfaces on EX Series switches. 


This topic includes: 


Configuring Security Associations 


When you configure a security association (SA), include your choices for authentication, encryption, 
direction, mode, protocol, and security parameter index (SPI). 


To configure a security association: 
1. Specify a name for the security association: 


[edit security ipsec] 


user@switch# set security-association sa-name 


2. Specify the mode of the security association: 


[edit security ipsec security-association sa-name] 


user@switch# set mode transport 


3. Specify the type of security association: 


[edit security ipsec security-association 


user@switch# set type manual 


4. Specify the direction of the security association: 


[edit security ipsec security-association 


user@switch# set direction bidirectional 


5. Specify the value of the security parameter index: 


[edit security ipsec security-association 


user@switch# set spi spi-value 


6. Specify the type of authentication to be used: 


[edit security ipsec security-association 


user@switch# set authentication algorithm type 


7. Specify the encryption algorithm and key: 


[edit security ipsec security-association 


Sa-name] 


Sa-name] 


Sa-name] 


Sa-name] 


Sa-name] 


user@switch# set encryption algorithm algorithm key type 


Securing OPSFv3 Networks 


You can secure the OSPFv3 network by applying the SA to the OSPF v3 configuration. 


To secure the OSPFv3 network: 





[edit protocols ospf3 area area-number interfac 


user@switch# set ipsec-sa sa-name 


interfac 


] 
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| Example: Configuring IPsec Authentication for an OSPF Interface 


IN THIS SECTION 
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Configuration | 263 
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This example shows how to enable IP Security (IPsec) authentication for an OSPF interface. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices or the 
Junos OS Interfaces Configuration Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


You can use IPsec authentication for both OSPFv2 and OSPFv3. You configure the actual IPsec 
authentication separately and apply it to the applicable OSPF configuration. 


OSPFv2 


Beginning with Junos OS Release 8.3, you can use IPsec authentication to authenticate OSPFv2 interfaces, 
the remote endpoint of a sham link, and the OSPF v2 virtual link by using manual security associations 
(SAs) to ensure that a packet's contents are secure between the routing devices. 
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NOTE: You can configure IPsec authentication together with either MD5 or simple authentication. 


To enable IPsec authentication, do one of the following: 


e For an OSPF v2 interface, include the ipsec-sa name statement for a specific interface: 
interface interface-name ipsec-sa name; 
e Fora remote sham link, include the ispec-sa name statement for the remote end point of the sham link: 
sham-link-remote address ipsec-sa name; 
NOTE: If a Layer 3 VPN configuration has multiple sham links with the same remote endpoint 
IP address, you must configure the same IPsec security association for all the remote endpoints. 
You configure a Layer 3 VPN at the [edit routing-instances routing-instance-name instance-type] 


hierarchy level. For more information about Layer 3 VPNs, see the Junos OS VPNs Library for 
Routing Devices. 


e For a virtual link, include the ipsec-sa name statement for a specific virtual link: 


virtual-link neighbor-id router-id transit-area area-id ipsec-sa name; 


OSPFv3 


OSPFv3 does not have a built-in authentication method and relies on IPsec to provide this functionality. 
You use IPsec authentication to secure OSPFv3 interfaces and protect OSPF v3 virtual links by using manual 
SAs to ensure that a packet’s contents are secure between the routing devices. 


To apply authentication, do one of the following: 


e For an OSPFv3 interface, include the ipsec-sa name statement for a specific interface: 


interface interface-name ipsec-sa name; 


e For a virtual link, include the ipsec-sa name statement for a specific virtual link: 


virtual-link neighbor-id router-id transit-area area-id ipsec-sa name; 


Tasks to Complete for Both OSPFv2 and OSPFv3 


In this 


example, you perform the following tasks: 


1. Configure IPsec authentication. To do this, define a manual SA named sai and specify the processing 


direction, the protocol used to protect IP traffic, the security parameter index (SPI), and the authentication 


algorithm and key. 


a. 


Configure the following option at the [edit security ipsec security-association sa-name mode] 
hierarchy level: 


transport—Specifies transport mode. This mode protects traffic when the communication endpoint 
and the cryptographic endpoint are the same. The data portion of the IP packet is encrypted, but 
the IP header is not. 


. Configure the following option at the [edit security ipsec security-association sa-name manual 


direction] hierarchy level: 


bidirectional—Defines the direction of IPsec processing. By specifying bidrectional, the same 
algorithms, keys, and security paramater index (SPI) values you configure are used in both directions. 


. Configure the following options at the [edit security ipsec security-association sa-name manual 


direction bidirectional] hierarchy level: 


protocol—Defines the IPsec protocol used by the manual SA to protect IP traffic. You can specify 
either the authentication header (AH) or the Encapsulating Security Payload (ESP). If you specify 
AH, which you do in this example, you cannot configure encryption. 


spi—Configures the SPI for the manual SA. An SPI is an arbitrary value that uniquely identifies which 
SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to 
use to secure every packet. The receiving host uses the SPI to identify and select the encryption 
algorithm and key used to decrypt packets. In this example, you specify 256. 


authentication—Configures the authentication algorithm and key. The algorithm option specifies 
the hash algorithm that authenticates packet data. In this example, you specify hmac-md5-96, which 
produces a 128-bit digest. The key option indicates the type of authentication key. In this example, 
you specify ascii-text-key, which is 16 ASCII characters for the hmac-md5-96 algorithm. 


2. Enable IPsec authentication on OSPF interface so-0/2/0.0 in the backbone area (area 0.0.0.0) by 
including the name of the manual SA sai that you configured at the [edit security ipsec] hierarchy level. 


Configuration 


IN THIS SECTION 
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Configuring Security Associations 


CLI Quick Configuration 


To quickly configure a manual SA to be used for IPsec authentication on an OSPF interface, copy the 
following commands, remove any line breaks, and then paste the commands into the CLI. 


[edit] 

set security ipsec security-association sa1 

set security ipsec security-association sa1 mode transport 

set security ipsec security-association sa1 manual direction bidirectional 

set security ipsec security-association sa1 manual direction bidirectional protocol ah 

set security ipsec security-association sa1 manual direction bidirectional spi 256 

set security ipsec security-association sa1 manual direction bidirectional authentication algorithm hmac-md5-96 
key ascii-text 123456789012abcd 


Step-by-Step Procedure 


To configure a manual SA to be used on an OSPF interface: 


1. Specify a name for the SA. 


[edit] 
user@host# edit security ipsec security-association sai 


ND 


. Specify the mode of the SA. 


[edit security ipsec security-association sa1 ] 
user@host# set mode transport 


3. Configure the direction of the manual SA. 


[edit security ipsec security-association sa1 ] 
user@host# set manual direction bidirectional 


4. Configure the IPsec protocol to use. 


[edit security ipsec security-association sa1 ] 
user@host# set manual direction bidirectional protocol ah 


5. Configure the value of the SPI. 
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[edit security ipsec security-association sa1 ] 
user@host# set manual direction bidirectional spi 256 


6. Configure the authentication algorithm and key. 


[edit security ipsec security-association sa1 ] 
user@host# set manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text 


123456789012abcd 


7. |If you are done configuring the device, commit the configuration. 


[edit security ipsec security-association sa1 ] 


user@host# commit 


NOTE: Repeat this entire configuration on all peer OSPF routing devices. 


Results 
Confirm your configuration by entering the show security ipsec command. If the output does not display 


the intended configuration, repeat the instructions in this example to correct the configuration. 


NOTE: After you configure the password, you do not see the password itself. The output displays 


the encrypted form of the password you configured. 


user@host# show security ipsec 
security-association sa1 { 
mode transport; 
manual { 
direction bidirectional { 
protocol ah; 
spi 256; 
authentication { 


algorithm hmac-md5-96; 
key ascii-text "$9$AP5Hp1RcyIMLxSygoZUHk1REHKMVwY2o0Jx7jHq.zF69A0OR"; ## SECRET-DATA 
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Enabling IPsec Authentication for an OSPF Interface 


CLI Quick Configuration 
To quickly apply a manual SA used for IPsec authentication to an OSPF interface, copy the following 
command and paste it into the CLI. 


[edit] 
set protocols ospf area 0.0.0.0 interface so-0/2/0 ipsec-sa sai 


Step-by-Step Procedure 


To enable IPsec authentication for an OSPF interface: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Specify the interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# edit interface so-0/2/0 


3. Apply the IPsec manual SA. 


[edit protocols ospf area 0.0.0.0 interface so-0/2/0.0] 
user@host# set ipsec-sa sa1 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 interface so-0/2/0.0] 
user@host# commit 
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NOTE: Repeat this entire configuration on all peer OSPF routing devices. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface so-0/2/0.0 { 
ipsec-sa sa1; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 
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Confirm that the configuration is working properly. 


Verifying the IPsec Security Association Settings 


Purpose 

Verify the configured IPsec security association settings. Verify the following information: 
e The Security association field displays the name of the configured security association. 
e The SPI field displays the value you configured. 

e The Mode field displays transport mode. 


e The Type field displays manual as the type of security association. 


Action 


From operational mode, enter the show ipsec security-associations command. 


268 


Verifying the IPsec Security Association on the OSPF Interface 


Purpose 


Verify that the IPsec security association that you configured has been applied to the OSPF interface. 
Confirm that the IPSec SA name field displays the name of the configured IPsec security association. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


SEE ALSO 


Security Services Configuration Guidelines in the Junos OS Administration Library 


IPsec Services Configuration Guidelines in the Junos OS Services Interfaces Library for Routing Devices 
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Configuring OSPF Routing Instances 
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| Understanding OSPF Routing Instances 


A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of 
interfaces belongs to the routing tables, and the OSPF routing protocol parameters control the information 
in the routing tables. You can further install routes learned from OSPF routing instances into routing tables 
in the OSPF routing table group. 


NOTE: The default routing instance, master, refers to the main inet.0 routing table. The master 
routing instance is reserved and cannot be specified as a routing instance. 


You can configure the following types of routing instances: 


e OSPFv2—Forwarding, Layer 2 virtual private network (VPN), nonforwarding, VPN routing and forwarding 
(VRF), virtual router, and virtual private LAN service (VPLS). 


e OSPFv3—Nonforwarding, VRF, and virtual router. 


Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure 
a routing instance with the name my-instance, the corresponding IP unicast table is my-instance.inet.0. 
All routes for my-instance are installed into my-instance.inet.0. 


You can also configure multiple routing instances of OSPF. 


Minimum Routing-Instance Configuration for OSPFv2 


To configure a routing instance for OSPFv2, you must include at least the following statements in the 
configuration: 
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[edit] 
routing-instances { 
routing-instance-name { 
interface interface-name; 
instance-type (forwarding | |2vpn | no-forwarding | virtual-router | vpls | vrf); 
route-distinguisher (as-number:number | ip-address:number), 
vrf-import [ policy-names ]; 
vrf-export [ policy-names ]; 
protocols { 
ospf { 
... ospf-configuration ... 


NOTE: You can configure a logical interface under only one routing instance. 


Minimum Routing-Instance Configuration for OSPFv3 


To configure a routing instance for OSPFv3, you must include at least the following statements in the 


configuration: 


[edit] 
routing-instances { 
routing-instance-name { 
interface interface-name; 
instance-type (no-forwarding | virtual-router | vrf); 
vrf-import [ policy-names ]; 
vrf-export [ policy-names ]; 
protocols { 
ospf3 { 
... ospf3-configuration ... 
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NOTE: You can configure a logical interface under only one routing instance. 


Multiple Routing Instances of OSPF 


Multiple instances of OSPF are used for Layer 3 VPN implementations. The multiple instances of OSPF 
keep routing information for different VPNs separate. The VRF instance advertises routes from the customer 
edge (CE) router to the provider edge (PE) router and advertises routes from the PE router to the CE router. 
Each VPN receives only routing information belonging to that VPN. 


You can create multiple instances of OSPF by including statements at the following hierarchy levels: 


e [edit routing-instances routing-instance-name (ospf | ospf3)] 


e [edit logical-systems logical-system-name routing-instances routing-instance-name (ospf | ospf3)] 


Installing Routes from OSPF Routing Instances into the OSPF Routing Table 
Group 


To install routes learned from OSPF routing instances into routing tables in the OSPF routing table group, 


include the rib-group statement: 


rib-group group-name; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 


for this statement. 
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IN THIS SECTION 


Requirements | 273 
Overview | 273 
Configuration | 275 


Verification | 280 


273 


This example shows how to configure multiple routing instances of OSPF. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Overview 


When you configure multiple routing instances of OSPF, we recommend that you perform the following 
tasks: 


1. Configure the OSPFv2 or OSPFv3 default instance at the [edit protocols (ospf | ospf3)] and [edit 
logical-systems logical-system-name protocols (ospf | ospf3)] hierarchy levels with the statements 
needed for your network so that routes are installed in inet.0 and in the forwarding table. 

Make sure to include the routing table group. 


2. Configure an OSPFv2 or OSPFv3 routing instance for each additional OSPFv2 or OSPF v3 routing 
entity, configuring the following: 


e Interfaces 
e Routing options 
e OSPF protocol statements belonging to that entity 


e Routing table group 


3. Configure a routing table group to install routes from the default route table, inet.0, into a routing 
instance’s route table. 


4. Configure a routing table group to install routes from a routing instance into the default route table, 
inet.0. 
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NOTE: Nonforwarding routing instances do not have forwarding tables that correspond to 
their routing tables. 


5. Create an export policy to export routes with a specific tag, and use that tag to export routes back into 
the instances. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers User 
Guide. 


Figure 20 on page 274 shows how you can use multiple routing instances of OSPFv2 or OSPFv3 to segregate 
prefixes within a large network. The network consists of three administrative entities: voice-policy, 
other-policy, and the default routing instance. Each entity is composed of several geographically separate 
sites that are connected by the backbone and managed by the backbone entity. 


Figure 20: Configuration for Multiple Routing Instances 
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Sites A and D belong to the voice-policy routing instance. Sites B and C belong to the other-policy instance. 
Device 1 and Device 3 at the edge of the backbone connect the routing instances. Each runs a separate 
OSPF or OSPF v3 instance (one per entity). 


Device 1 runs three OSPFv2 or OSPFv3 instances: one each for Site A (voice-policy), Site C (other-policy), 
and the backbone, otherwise known as the default instance. Device 3 also runs three OSPFv2 or OSPFv3 
instances: one each for Site B (other-policy), Site D (voice-policy), and the backbone (default instance). 


When Device 1 runs the OSPFv2 or OSPF v3 instances, the following occur: 


e Routes from the default instance routing table are placed in the voice-policy and other-policy instance 
routing tables. 


e Routes from the voice-policy routing instance are placed in the default instance routing table. 
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e Routes from the other-policy routing instance are placed in the default instance routing table. 
e Routes from the voice-policy routing instance do not enter the other-policy instance routing table. 


e Routes from the other-policy routing instance do not enter the voice-policy instance routing table. 


Configuration 


CLI Quick Configuration 

To quickly configure multiple routing instances of OSPF, copy the following commands, paste them into 
a text file, remove any line breaks, change any details necessary to match your network configuration, 
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from 
configuration mode. 


Configuration on Device 1: 


[edit] 

set routing-instances voice-policy interface so-2/2/2 

set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-2/2/2 

set routing-instances other-policy interface so-4/2/2 

set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-4/2/2 

set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.O voice-policy.inet.0 other-policy.inet.O 
] 

set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.O inet.0 ] 

set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.O inet.O ] 

set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 

set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2 


Configuration on Device 3: 


[edit] 

set routing-instances voice-policy interface so-3/2/2 

set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface so-3/2/2 

set routing-instances other-policy interface so-5/2/2 

set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface so-5/2/2 

set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.O voice-policy.inet.0 other-policy.inet.O 
] 

set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.O inet.0 ] 

set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.O inet.O ] 

set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2 

set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2 


Step-by-Step Procedure 
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To configure multiple routing instances of OSPF: 


1. Configure the routing instances for voice-policy and other-policy. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit routing-instances 
protocols] hierarchy level. 


[edit] 

user@D1# set routing-instances voice-policy interface so-2/2/2 

user@D11# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface 
so-2/2/2 

user@D11# set routing-instances other-policy interface so-4/2/2 

user@D11# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface 
so-4/2/2 


[edit] 

user@D3# set routing-instances voice-policy interface so-3/2/2 

user@D3# set routing-instances voice-policy protocols ospf rib-group voice-to-inet area 0.0.0.0 interface 
so-3/2/2 

user@D3#set routing-instances other-policy interface so-5/2/2 

user@D3# set routing-instances other-policy protocols ospf rib-group other-to-inet area 0.0.0.0 interface 
so-5/2/2 


2. Configure the routing table group inet-to-voice-and-other to take routes from inet.O (default routing 
table) and place them in the voice-policy.inet.0 and other-policy.inet.0 routing tables. 


[edit] 
user@D1# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.O 
other-policy.inet.0 ] 


[edit] 
user@D3# set routing-options rib-groups inet-to-voice-and-other import-rib [ inet.0 voice-policy.inet.O 
other-policy.inet.0 ] 


3. Configure the routing table group voice-to-inet to take routes from voice-policy.inet.0 and place them 
in the inet.O default routing table. 


[edit] 
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user@D1# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 ] 


[edit] 
user@D3# set routing-options rib-groups voice-to-inet import-rib [ voice-policy.inet.0 inet.0 | 


4. Configure the routing table group other-to-inet to take routes from other-policy.inet.0 and place them 
in the inet.0 default routing table. 


[edit] 
user@D1# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.O inet.0O ] 


[edit] 
user@D3# set routing-options rib-groups other-to-inet import-rib [ other-policy.inet.O inet.0O ] 


5. Configure the default OSPF instance. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit routing-instances 
protocols] hierarchy level. 


[edit] 
user@D11# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-2/2/2 
user@D11# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-4/2/2 


[edit] 
user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-3/2/2 
user@D3# set protocols ospf rib-group inet-to-voice-and-other area 0.0.0.0 interface so-5/2/2 


6. If you are done configuring the device, commit the configuration. 
[edit] 


user@host# commit 


Results 
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Confirm your configuration by entering the show routing-instances, show routing-options, and show 
protocols ospf commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 


Configuration on Device 1: 


user@D1# show routing-instances 
voice-policy { 
interface so-2/2/2.0; 
protocols { 
ospf { 
rib-group voice-to-inet; 
area 0.0.0.0 { 
interface so-2/2/2.0; 


} 
other-policy { 
interface so-4/2/2.0; 
protocols { 
ospf { 
rib-group other-to-inet; 
area 0.0.0.0 { 
interface so-4/2/2.0; 


user@D1# show routing-options 
rib-groups { 
inet-to-voice-and-other { 
import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.O ]; 
} 
voice-to-inet { 
import-rib [ voice-policy.inet.O inet.0 J; 
} 
other-to-inet { 
import-rib [ other-policy.inet.O inet.O ]; 


user@D1# show protocols ospf 
rib-group inet-to-voice-and-other; 
area 0.0.0.0 { 

interface so-2/2/2.0; 

interface so-4/2/2.0; 


Configuration on Device 3: 


user@D3# show routing-instances 
voice-policy { 
interface so-3/2/2.0; 
protocols { 
ospf { 
rib-group voice-to-inet; 
area 0.0.0.0 { 
interface so-3/2/2.0; 


} 
other-policy { 
interface so-5/2/2.0; 
protocols { 
ospf { 
rib-group other-to-inet; 
area 0.0.0.0 { 
interface so-5/2/2.0; 


user@D3# show routing-options 
rib-groups { 
inet-to-voice-and-other { 
import-rib [ inet.0 voice-policy.inet.0 other-policy.inet.0 J; 
} 
voice-to-inet { 
import-rib [ voice-policy.inet.O inet.0O J; 
} 
other-to-inet { 
import-rib [ other-policy.inet.O inet.O ]; 
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user@D3# show protocols ospf 
rib-group inet-to-voice-and-other; 
area 0.0.0.0 { 

interface so-3/2/2.0; 

interface so-5/2/2.0; 


To confirm your OSPFv3 configuration, enter the show routing-instances, show routing-options, and 
show protocols ospf3 commands. 


Verification 
Confirm that the configuration is working properly. 


Verifying the Routing Instances 


Purpose 


Verify the configured routing instance settings. 


Action 


From operational mode, enter the show route instance detail command. 


SEE ALSO 


rib-group (Protocols OSPF) | 737 


RELATED DOCUMENTATION 


Routing Instances Overview 


CHAPTER 


Configure OSPF Timers 


Configuring OSPF Timers | 282 
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Configuring OSPF Timers 


IN THIS SECTION 


@ OSPF Timers Overview | 282 
@ Example: Configuring OSPF Timers | 283 


| OSPF Timers Overview 


OSPF routing devices constantly track the status of their neighbors, sending and receiving hello packets 
that indicate whether each neighbor still is functioning, and sending and receiving link-state advertisement 
(LSA) and acknowledgment packets. OSPF sends packets and expects to receive packets at specified 
intervals. 


You configure OSPF timers on the interface of the routing device participating in OSPF. Depending on 
the timer, the configured interval must be the same on all routing devices on a shared network (area). 


You can configure the following OSPF timers: 


e Hello interval—Routing devices send hello packets at a fixed interval on all interfaces, including virtual 
links, to establish and maintain neighbor relationships. The hello interval specifies the length of time, in 
seconds, before the routing device sends a hello packet out of an interface. This interval must be the 
same on all routing devices on a shared network. By default, the routing device sends hello packets every 
10 seconds (broadcast and point-to-point networks) and 30 seconds (nonbroadcast multiple access 
(NBMA) networks). 


e Poll interval—(OSPFv2, Nonbroadcast networks only) Routing devices send hello packets for a longer 
interval on nonbroadcast networks to minimize the bandwidth required on slow WAN links. The poll 
interval specifies the length of time, in seconds, before the routing device sends hello packets out of the 
interface before establishing adjacency with a neighbor. By default, the routing device sends hello packets 
every 120 seconds until active neighbors are detected. 


Once the routing device detects an active neighbor, the hello packet interval changes from the time 
specified in the poll interval to the time specified in the hello interval. 


e LSA retransmission interval—When a routing device sends LSAs to its neighbors, the routing device 
expects to receive an acknowledgment packet from each neighbor within a certain amount of time. The 
LSA retransmission interval specifies the length of time, in seconds, that the routing device waits to 
receive an LSA packet before retransmitting the LSA to an interface’s neighbors. By default, the routing 
device waits 5 seconds for an acknowledgment before retransmitting the LSA. 
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e Dead interval—If a routing device does not receive a hello packet from a neighbor within a fixed amount 
of time, the routing device modifies its topology database to indicate that the neighbor is nonoperational. 
The dead interval specifies the length of time, in seconds, that the routing device waits before declaring 
that a neighboring routing device is unavailable. This is an interval during which the routing device 
receives no hello packets from the neighbor. This interval must be the same on all routing devices ona 
shared network. By default, this interval is four times the default hello interval, which is 40 seconds 
(broadcast and point-to-point networks) and 120 seconds (NBMA networks). 


e Transit delay—Before a link-state update packet is propagated out of an interface, the routing device 
must increase the age of the packet. The transit delay sets the estimated time required to transmit a 
link-state update on the interface. By default, the transit delay is 1 second. You should never have to 
modify the transit delay time. 


SEE ALSO 


| Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
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Requirements | 283 
Overview | 284 
Configuration | 285 


Verification | 290 


This example shows how to configure the OSPF timers. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 
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e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 
e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 


page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


The default OSPF timer settings are optimal for most networks. However, depending on your network 
requirements, you might need to modify the timer settings. This example explains why you might need to 
modify the following timers: 


e Hello interval 
e Dead interval 
e LSA retransmission interval 


e Transit delay 
Hello Interval and Dead Interval 


The hello interval and the dead interval optimize convergence times by efficiently tracking neighbor status. 
By lowering the values of the hello interval and the dead interval, you can increase the convergence of 
OSPF routes if a path fails. These intervals must be the same on all routing devices on a shared network. 
Otherwise, OSPF cannot establish the appropriate adjacencies. 


In the first example, you lower the hello interval to 2 seconds and the dead interval to 8 seconds on 
point-to-point OSPF interfaces fe-0/0/1 and fe-1/0/1 in area 0.0.0.0 by configuring the following settings: 


e hello-interval—Specifies the length of time, in seconds, before the routing device sends a hello packet 
out of an interface. By default, the routing device sends hello packets every 10 seconds. The range is 
from 1 through 255 seconds. 


e dead-interval—Specifies the length of time, in seconds, that the routing device waits before declaring 
that a neighboring routing device is unavailable. This is an interval during which the routing device 
receives no hello packets from the neighbor. By default, the routing device waits 40 seconds (four times 
the hello interval). The range is 1 through 65,535 seconds. 


LSA Retransmission Interval 


The link-state advertisement (LSA) retransmission interval optimizes the sending and receiving of LSA and 
acknowledgement packets. You must configure the LSA retransmission interval to be equal to or greater 
than 3 seconds to avoid triggering a retransmit trap because the Junos OS delays LSA acknowledgments 
by up to 2 seconds. If you have a virtual link, you might find increased performance by increasing the value 
of the LSA retransmission interval. 


In the second example, you increase the LSA retransmission timer to 8 seconds on OSPF interface fe-0/0/1 
in area 0.0.0.1 by configuring the following setting: 


e retransmit-interval—Specifies the length of time, in seconds, that the routing device waits to receive an 
LSA packet before retransmitting LSA to an interface’s neighbors. By default, the routing device 
retransmits LSAs to its neighbors every 5 seconds. The range is from 1 through 65,535 seconds. 


Transit Delay 


The transit delay sets the time the routing device uses to age a link-state update packet. If you have a slow 
link (for example, one with an average propagation delay of multiple seconds), you should increase the 
age of the packet by a similar amount. Doing this ensures that you do not receive a packet back that is 
younger than the original copy. 


In the final example, you increase the transit delay to 2 seconds on OSPF interface fe-1/0/1 in area 0.0.0.1. 
By configuring the following setting, this causes the routing device to age the link-state update packet by 
2 seconds: 


e transit-delay—Sets the estimated time required to transmit a link-state update on the interface. You 
should never have to modify the transit delay time. By default, the routing device ages the packet by 1 
second. The range is from 1 through 65,535 seconds. 


Configuration 


IN THIS SECTION 


@ = Configuring the Hello Interval and the Dead Interval | 285 
@ Controlling the LSA Retransmission Interval | 287 
@ = Specifying the Transit Delay | 288 


Configuring the Hello Interval and the Dead Interval 


CLI Quick Configuration 

To quickly configure the hello and dead intervals, paste them into a text file, remove any line breaks, change 
any details necessary to match your network configuration, copy and paste the commands into the CLI at 
the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
set protocols ospf area 0.0.0.0 interface fe-0/0/1 hello-interval 2 
set protocols ospf area 0.0.0.0 interface fe-0/0/1 dead-interval 8 
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set protocols ospf area 0.0.0.0 interface fe-1/0/1 hello-interval 2 
set protocols ospf area 0.0.0.0 interface fe-1/0/1 dead-interval 8 


Step-by-Step Procedure 


To configure the hello and dead intervals: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 


level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Specify the interfaces. 


[edit protocols ospf area 0.0.0.0] 
user@host# set interface fe-0/0/1 
user@host# set interface fe-1/0/1 


3. Configure the hello interval. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-0/0/1 hello-interval 2 
user@host# set interface fe-1/0/1 hello-interval 2 


4. Configure the dead interval. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-0/0/1 dead-interval 8 
user@host# set interface fe-1/0/1 dead-interval 8 


5. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# commit 
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NOTE: Repeat this entire configuration on all routing devices in a shared network. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0 { 
hello-interval 2; 
dead-interval 8; 


} 

interface fe-1/0/1.0 { 
hello-interval 2; 
dead-interval 8; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 
Controlling the LSA Retransmission Interval 


CLI Quick Configuration 


To quickly configure the LSA retransmission interval, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, copy and 
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 


[edit] 
set protocols ospf area 0.0.0.1 interface fe-0/0/1 retransmit-interval 8 


Step-by-Step Procedure 


To configure the LSA retransmission interval: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


2. Specify the interface. 


[edit protocols ospf area 0.0.0.1] 
user@host# set interface fe-0/0/1 


3. Configure the LSA retransmission interval. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface fe-0/0/1 retransmit-interval 8 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface fe-0/0/1.0 { 
retransmit-interval 8; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Specifying the Transit Delay 


CLI Quick Configuration 


To quickly configure the transit delay, copy the following commands, paste them into a text file, remove 
any line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
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set protocols ospf area 0.0.0.1 interface fe-1/0/1 transit-delay 2 


Step-by-Step Procedure 


To configure the transit delay: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.1 


2. Specify the interface. 


[edit protocols ospf area 0.0.0.1] 
user@host# set interface fe-1/0/1 


3. Configure the transit delay. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# set interface fe-1/0/1 transit-delay 2 


4. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.1 ] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface fe-1/0/1.0 { 
transit-delay 2; 
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To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Timer Configuration 


Purpose 


Verify that the interface for OSPF or OSPFv3 has been configured with the applicable timer values. Confirm 
that the Hello field, the Dead field, and the ReXmit field display the values that you configured. 


Action 


From operational mode, enter the show ospf interface detail for OSPFv2, and enter the show ospf3 
interface detail command for OSPFv3. 
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Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
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Configuring OSPF Fault Detection using BFD 


IN THIS SECTION 


Understanding BFD for OSPF | 292 
Example: Configuring BFD for OSPF | 294 
Understanding BFD Authentication for OSPF | 299 


Configuring BFD Authentication for OSPF | 301 


| Understanding BFD for OSPF 


The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures 
in a network. BFD works with a wide variety of network environments and topologies. A pair of routing 
devices exchange BFD packets. Hello packets are sent at a specified, regular interval. A neighbor failure 
is detected when the routing device stops receiving a reply after a specified interval. The BFD failure 
detection timers have shorter time limits than the OSPF failure detection mechanisms, so they provide 


faster detection. 


The BFD failure detection timers are adaptive and can be adjusted to be faster or slower. The lower the 
BFD failure detection timer value, the faster the failure detection and vice versa. For example, the timers 
can adapt to a higher value if the adjacency fails (that is, the timer detects failures more slowly). Or a 
neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher 
value when a BFD session flap occurs more than three times in a span of 15 seconds. A back-off algorithm 
increases the receive (Rx) interval by two if the local BFD instance is the reason for the session flap. The 
transmission (Tx) interval is increased by two if the remote BFD instance is the reason for the session flap. 
You can use the clear bfd adaptation command to return BFD interval timers to their configured values. 
The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on 


the routing device. 


NOTE: QFX5000 Series switches and EX4600 switches do not support minimum interval values 
of less than 1 second. 


NOTE: BFD is supported for OSPFv3 in Junos OS Release 9.3 and later. 
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NOTE: For branch SRX Series devices, we recommend 1000 ms as the minimum keepalive time 
interval for BFD packets. 


You can configure the following BFD protocol settings: 


e detection-time threshold—Threshold for the adaptation of the detection time. When the BFD session 


detection time adapts to a value equal to or greater than the configured threshold, a single trap and a 


single system log message are sent. 


e full-neighbors-only—Ability to establish BFD sessions only for OSPF neighbors with full neighbor 
adjacency. The default behavior is to establish BFD sessions for all OSPF neighbors. This setting is 


available in Junos OS Release 9.5 and later. 


e minimum-interval—Minimum transmit and receive interval for failure detection. This setting configures 


both the minimum interval after which the local routing device transmits hello packets and the minimum 


interval after which the routing device expects to receive a reply from the neighbor with which it has 


established a BFD session. Both intervals are in milliseconds. You can also specify the minimum transmit 


and receive intervals separately using the transmit-interval minimum-interval and 


minimum-receive-interval statements. 


NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum 
interval for BFD of less than 100 ms for Routing Engine-based sessions and 10 ms for distributed 
BFD sessions can cause undesired BFD flapping. 


Depending on your network environment, these additional recommendations might apply: 


e 


e 


e 


e 


For large-scale network deployments with a large number of BFD sessions, specify a minimum 
interval of no less than 500 ms. An interval of 1000 ms is recommended to avoid any 
instability issues. 


For very large-scale network deployments with a large number of BFD sessions, contact 
Juniper Networks customer support for more information. 


For BFD sessions to remain up during a Routing Engine switchover event when nonstop 
active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing 
Engine-based sessions. Without NSR, Routing Engine-based sessions can have a minimum 
interval of 100 ms. In OSPFv3, BFD is always based in the Routing Engine, meaning that 
BFD is not distributed. For distributed BFD sessions with NSR configured, the minimum 
interval recommendations are unchanged and depend only on your network deployment. 


On a single QFX5100 switch, when you add a QFX-EM-4Q expansion module, specify a 
minimum interval higher than 1000 ms. 
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minimum-receive-interval—Minimum receive interval for failure detection. This setting configures the 


minimum receive interval, in milliseconds, after which the routing device expects to receive a hello packet 
from a neighbor with which it has established a BFD session. You can also specify the minimum receive 
interval using the minimum-interval statement. 


multiplier—Multiplier for hello packets. This setting configures the number of hello packets that are not 


received by a neighbor, which causes the originating interface to be declared down. By default, three 
missed hello packets cause the originating interface to be declared down. 


no-adaptation—Disables BFD adaption. This setting disables BFD sessions from adapting to changing 
network conditions. This setting is available in Junos OS Release 9.0 and later. 


NOTE: We recommend that you do not disable BFD adaptation unless it is preferable not to 
have BFD adaptation in your network. 


transmit-interval minimum-interval—Minimum transmit interval for failure detection. This setting 
configures the minimum transmit interval, in milliseconds, at which the local routing device transmits 
hello packets to the neighbor with which it has established a BFD session. You can also specify the 
minimum transmit interval using the minimum-interval statement. 


transmit-interval threshold—Threshold for the adaptation of the BFD session transmit interval. When 
the transmit interval adapts to a value greater than the threshold, a single trap and a single system log 


message are sent. The threshold value must be greater than the minimum transmit interval. If you attempt 
to commit a configuration with a threshold value less than the minimum transmit interval, the routing 
device displays an error and does not accept the configuration. 


version—BFD version. This setting configures the BFD version used for detection. You can explicitly 


configure BFD version 1, or the routing device can automatically detect the BFD version. By default, 
the routing device automatically detects the BFD version automatically, which is either O or 1. 


You can also trace BFD operations for troubleshooting purposes. 


| Example: Configuring BFD for OSPF 


IN THIS SECTION 


Requirements | 295 
Overview | 295 
Configuration | 296 


Verification | 298 
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This example shows how to configure the Bidirectional Forwarding Detection (BFD) protocol for OSPF. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Junos OS Network Interfaces Library for Routing Devices. 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71. 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


An alternative to adjusting the OSPF hello interval and dead interval settings to increase route convergence 
is to configure BFD. The BFD protocol is a simple hello mechanism that detects failures in a network. The 
BFD failure detection timers have shorter timer limits than the OSPF failure detection mechanisms, thereby 
providing faster detection. 


BFD is useful on interfaces that are unable to detect failure quickly, such as Ethernet interfaces. Other 
interfaces, such as SONET interfaces, already have built-in failure detection. Configuring BFD on those 
interfaces is unnecessary. 


You configure BFD on a pair of neighboring OSPF interfaces. Unlike the OSPF hello interval and dead 
interval settings, you do not have to enable BFD on all interfaces in an OSPF area. 


In this example, you enable failure detection by including the bfd-liveness-detection statement on the 
neighbor OSPF interface fe-0/1/0 in area 0.0.0.0 and configure the BFD packet exchange interval to 
300 milliseconds, configure 4 as the number of missed hello packets that causes the originating interface 
to be declared down, and configure BFD sessions only for OSPF neighbors with full neighbor adjacency 
by including the following settings: 


e full-neighbors-only—In Junos OS Release 9.5 and later, configures the BFD protocol to establish BFD 
sessions only for OSPF neighbors with full neighbor adjacency. The default behavior is to establish BFD 
sessions for all OSPF neighbors. 


e minimum-interval—Configures the minimum interval, in milliseconds, after which the local routing device 
transmits hello packets as well as the minimum interval after which the routing device expects to receive 
a reply from the neighbor with which it has established a BFD session. You can configure a number in 
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the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive 
intervals separately using the transmit-interval minimum-interval and minimum-receive-interval 
statements. 


NOTE: BFD is an intensive protocol that consumes system resources. Specifying a minimum 
interval for BFD of less than 100 ms for Routing Engine-based sessions and 10 ms for distributed 
BFD sessions can cause undesired BFD flapping. 


Depending on your network environment, these additional recommendations might apply: 


e For large-scale network deployments with a large number of BFD sessions, specify a minimum 
interval of no less than 500 ms. An interval of 1000 ms is recommended to avoid any 
instability issues. 


NOTE: 

e For the bfdd process, the detection time interval set is lower than 300 ms. If 
there is a high priority process such as ppmd running on the system, the CPU 
might spend time on the ppmd process rather than the bfdd process. 


e For branch SRX Series devices, we recommend 1000 ms as the minimum 
keepalive time interval for BFD packets. 


e For very large-scale network deployments with a large number of BFD sessions, contact 
Juniper Networks customer support for more information. 


e For BFD sessions to remain up during a Routing Engine switchover event when nonstop 
active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing 
Engine-based sessions. For distributed BFD sessions with NSR configured, the minimum 
interval recommendations are unchanged and depend only on your network deployment. 


e multiplier—Configures the number of hello packets not received by a neighbor that causes the originating 
interface to be declared down. By default, three missed hello packets cause the originating interface to 
be declared down. You can configure a value in the range from 1 through 255. 


Configuration 


CLI Quick Configuration 

To quickly configure the BFD protocol for OSPF, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, copy and 
paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 
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[edit] 

set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection minimum-interval 300 
set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection multiplier 4 

set protocols ospf area 0.0.0.0 interface fe-0/0/1 bfd-liveness-detection full-neighbors-only 


Step-by-Step Procedure 


To configure the BFD protocol for OSPF on one neighboring interface: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


Nh 


. Specify the interface. 


[edit protocols ospf area 0.0.0.0] 
user@host# set interface fe-0/0/1 


3. Specify the minimum transmit and receive intervals. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-0/0/1 bfd-liveness-detection minimum-interval 300 


4. Configure the number of missed hello packets that cause the originating interface to be declared down. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-0/0/1 bfd-liveness-detection multiplier 4 


5. Configure BFD sessions only for OSPF neighbors with full neighbor adjacency. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# set interface fe-0/0/1 bfd-liveness-detection full-neighbors-only 
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6. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0 ] 
user@host# commit 


NOTE: Repeat this entire configuration on the other neighboring interface. 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0 { 
bfd-liveness-detection { 
minimum-interval 300; 
multiplier 4; 
full-neighbors-only; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 
Verifying the BFD Sessions 


Purpose 


Verify that the OSPF interfaces have active BFD sessions, and that session components have been 
configured correctly. 


Action 


From operational mode, enter the show bfd session detail command. 


Meaning 


The output displays information about the BFD sessions. 


e The Address field displays the IP address of the neighbor. 
e The Interface field displays the interface you configured for BFD. 


e The State field displays the state of the neighbor and should show Full to reflect the full neighbor 
adjacency that you configured. 


e The Transmit Interval field displays the time interval you configured to send BFD packets. 


e The Multiplier field displays the multiplier you configured. 


Understanding BFD Authentication for OSPF 


IN THIS SECTION 


@ ~_BFD Authentication Algorithms | 300 
@ ~~ Security Authentication Keychains | 301 
@ Strict Versus Loose Authentication | 301 


Bidirectional Forwarding Detection (BFD) enables rapid detection of communication failures between 
adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD 
over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using 
authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with 
Junos OS Release 9.6, Junos OS supports authentication for BFD sessions running over OSPFv2. BFD 
authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the 
Canada and United States version of the Junos OS image and is not available in the export version. 


You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating 
that configuration information with a security authentication keychain using the keychain name. 


The following sections describe the supported authentication algorithms, security keychains, and level of 
authentication that can be configured: 
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BFD Authentication Algorithms 


Junos OS supports the following algorithms for BFD authentication: 


e simple-password—Plain-text password. One to 16 bytes of plain text are used to authenticate the BFD 
session. One or more passwords can be configured. This method is the least secure and should be used 
only when BFD sessions are not subject to packet interception. 


e keyed-md5—Keyed Message Digest 5 hash algorithm for sessions with transmit and receive intervals 
greater than 100 ms. To authenticate the BFD session, keyed MD5 uses one or more secret keys 
(generated by the algorithm) and a sequence number that is updated periodically. With this method, 
packets are accepted at the receiving end of the session if one of the keys matches and the sequence 
number is greater than or equal to the last sequence number received. Although more secure than a 
simple password, this method is vulnerable to replay attacks. Increasing the rate at which the sequence 
number is updated can reduce this risk. 


meticulous-keyed-md5—Meticulous keyed Message Digest 5 hash algorithm. This method works in the 
same manner as keyed MD5, but the sequence number is updated with every packet. Although more 
secure than keyed MD5 and simple passwords, this method might take additional time to authenticate 
the session. 


keyed-sha-1—Keyed Secure Hash Algorithm | for sessions with transmit and receive intervals greater 


than 100 ms. To authenticate the BFD session, keyed SHA uses one or more secret keys (generated by 
the algorithm) and a sequence number that is updated periodically. The key is not carried within the 
packets. With this method, packets are accepted at the receiving end of the session if one of the keys 
matches and the sequence number is greater than the last sequence number received. 


meticulous-keyed-sha-1—Meticulous keyed Secure Hash Algorithm |. This method works in the same 
manner as keyed SHA, but the sequence number is updated with every packet. Although more secure 
than keyed SHA and simple passwords, this method might take additional time to authenticate the 
session. 


NOTE: Nonstop active routing (NSR) is not supported with the meticulous-keyed-md5 and 
meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might 
go down after a switchover. 


NOTE: QFX5000 Series switches and EX4600 switches do not support minimum interval values 
of less than 1 second. 
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Security Authentication Keychains 


The security authentication keychain defines the authentication attributes used for authentication key 
updates. When the security authentication keychain is configured and associated with a protocol through 
the keychain name, authentication key updates can occur without interrupting routing and signaling 
protocols. 


The authentication keychain contains one or more keychains. Each keychain contains one or more keys. 

Each key holds the secret data and the time at which the key becomes valid. The algorithm and keychain 
must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration 
prevents the BFD session from being created. 


BFD allows multiple clients per session, and each client can have its own keychain and algorithm defined. 
To avoid confusion, we recommend specifying only one security authentication keychain. 


Strict Versus Loose Authentication 


By default, strict authentication is enabled and authentication is checked at both ends of each BFD session. 
Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can 
configure loose checking. When loose checking is configured, packets are accepted without authentication 
being checked at each end of the session. This feature is intended for transitional periods only. 


Configuring BFD Authentication for OSPF 


IN THIS SECTION 


@ = Configuring BFD Authentication Parameters | 301 


@ Viewing Authentication Information for BFD Sessions | 303 


Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over 
OSPF v2. Routing instances are also supported. 


The following sections provide instructions for configuring and viewing BFD authentication on OSPF: 


Configuring BFD Authentication Parameters 


Only three steps are needed to configure authentication on a BFD session: 


1. Specify the BFD authentication algorithm for the OSPFv2 protocol. 
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2. Associate the authentication keychain with the OSPFv2 protocol. 


3. Configure the related security authentication keychain. 
To configure BFD authentication: 


1. Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or 
simple-password) to use for BFD authentication on an OSPF route or routing instance. 


[edit] 
user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection authentication algorithm 
keyed-sha-1 


NOTE: Nonstop active routing (NSR) is not supported with meticulous-keyed-md5 and 
meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms 
might go down after a switchover. 


2. Specify the keychain to be used to associate BFD sessions on the specified OSPF route or routing 
instance with the unique security authentication keychain attributes. 


This keychain should match the keychain name configured at the [edit security authentication 
key-chains] hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.1 interface if2-ospf bfd-liveness-detection authentication keychain 
bfd-ospf 


NOTE: The algorithm and keychain must be configured on both ends of the BFD session, 
and they must match. Any mismatch in configuration prevents the BFD session from being 
created. 


3. Specify the unique security authentication information for BFD sessions: 
e The matching keychain name as specified in Step 2. 


e At least one key, a unique integer between O and 63. Creating multiple keys enables multiple clients 
to use the BFD session. 


e The secret data used to allow access to the session. 


e The time at which the authentication key becomes active, in the format yyyy-mm-dd.hh:mm:ss. 
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[edit security] 


user@host# authentication-key-chains key-chain bfd-ospf key 53 secret $4BC123$ABC123 start-time 
2009-06-14.10:00:00 


4. (Optional) Specify loose authentication checking if you are transitioning from nonauthenticated sessions 
to authenticated sessions. 


[edit] 
user@host> set protocols ospf interface if2-ospf bfd-liveness-detection authentication loose-check 


5. (Optional) View your configuration using the show bfd session detail or show bfd session extensive 
command. 


6. Repeat the steps in this procedure to configure the other end of the BFD session. 


NOTE: BFD authentication is only supported in the Canada and United States version of the 
Junos OS image and is not available in the export version. 


Viewing Authentication Information for BFD Sessions 


You can view the existing BFD authentication configuration using the show bfd session detail and show 
bfd session extensive commands. 


The following example shows BFD authentication configured for the if2-ospf BGP group. It specifies the 
keyed SHA-1 authentication algorithm and a keychain name of bfd-ospf. The authentication keychain is 
configured with two keys. Key 1 contains the secret data “$ABC123$ABC123’ and a start time of June 
1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$ABC123$ABC123’ and a start time of June 
1, 2009, at 3:29:20 PM PST. 


[edit protocols ospf] 
area 0.0.0.1 { 
interface if2-ospf { 
bfd-liveness-detection { 
authentication { 
algorithm keyed-sha-1; 
key-chain bfd-ospf; 
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} 
[edit security] 
authentication key-chains { 
key-chain bfd-ospf { 
key 1{ 
secret “$ABC123$ABC123”; ## SECRET-DATA 
start-time “2009-6-1.09:46:02 -0700”; 
} 
key 2 { 
secret “$ABC123$ABC123”; 
start-time “2009-6-1.15:29:20 -0700”; ## SECRET-DATA 


If you commit these updates to your configuration, you see output similar to the following. In the output 
for the show bfd session detail command, Authenticate is displayed to indicate that BFD authentication 


is configured. 


show bfd session detail 


user@host# show bfd session detail 


Detect Transmit 
Address State Interface Time Interval Multiplier 
10.95 1433 Up $0=7// 11/0 .0 0.600 0.200 3 


Client OSPF, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate 
Session up time 3d 00:34 
Local diagnostic None, remote diagnostic None 


Remote state Up, version 1 





Replicated 


i Wsessitons,, J clients 





Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps 


For more information about the configuration, use the show bfd session extensive command. The output 
for this command provides the keychain name, the authentication algorithm and mode for each client in 
the session, and the overall BFD authentication configuration status, keychain name, and authentication 


algorithm and mode. 


305 


show bfd session extensive 


user@host# show bfd session extensive 


Detect Transmit 
Address State Interface Time Interval Multiplier 
LO sO. .33 Up SO=7/ 11/0 0 0.600 0.200 3 


Client OSPF, TX interval 0.200, RX interval 0.200, multiplier 3, Authenticate 


keychain bfd-ospf, algo keyed-md5, mode loose 


Session up time 3d 00:34 
Local diagnostic None, remote diagnostic None 


Remote state Up, version 1 





Replicated 

Min async interval 0.200, min slow interval 1.000 

Adaptive async tx interval 0.200, rx interval 0.200 

Local min tx interval 0.200, min rx interval 0.200, multiplier 3 

Remote min tx interval 0.100, min rx interval 0.100, multiplier 3 
Threshold transmission interval 0.000, Threshold for detection time 0.000 


Local discriminator 11, remote discriminator 80 





Echo mode disabled/inactive 
Authentication enabled/active, keychain bfd-ospf, algo keyed-sha-1, mode strict 


1 sessions, 1 clients 





Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps 
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Configuring Graceful Restart for OSPF 


IN THIS SECTION 


Graceful Restart for OSPF Overview | 307 

Example: Configuring Graceful Restart for OSPF | 309 

Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart | 315 
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart | 320 


Example: Disabling Strict LSA Checking for OSPF Graceful Restart | 324 


| Graceful Restart for OSPF Overview 


IN THIS SECTION 


@ ~~ Helper Mode for Graceful Restart | 308 
@ Planned and Unplanned Graceful Restart | 309 


Graceful restart allows a routing device undergoing a restart to inform its adjacent neighbors and peers 
of its condition. During a graceful restart, the restarting device and its neighbors continue forwarding 
packets without disrupting network performance. Because neighboring devices assist in the restart (these 
neighbors are called helper routers), the restarting device can quickly resume full operation without 
recalculating algorithms. 


NOTE: On a broadcast link with a single neighbor, when the neighbor initiates an OSPFv3 
graceful restart operation, the restart might be terminated at the point when the local routing 
device assumes the role of a helper. A change in the LSA is considered a topology change, which 
terminates the neighbor's restart operation. 


Graceful restart is disabled by default. You can either globally enable graceful restart for all routing protocols, 
or you can enable graceful restart specifically for OSPF. 
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This topic describes the following information: 


Helper Mode for Graceful Restart 


When a device enabled for OSPF graceful restart restarts, it retains routes learned before the restart in 
its forwarding table. The device does not allow new OSPF link-state advertisements (LSAs) to update the 
routing table. This device continues to forward traffic to other OSPF neighbors (or helper routers), and 
sends only a limited number of LSAs during the restart period. To reestablish OSPF adjacencies with 
neighbors, the restarting device must send a grace LSA to all neighbors. In response, the helper routers 
enter helper mode (the ability to assist a neighboring device attempting a graceful restart) and send an 
acknowledgment back to the restarting device. If there are no topology changes, the helper routers continue 
to advertise LSAs as if the restarting device had remained in continuous OSPF operation. 


NOTE: Helper mode is enabled by default when you start the routing platform, even if graceful 
restart is not enabled. You can disable helper mode specifically for OSPF. 


When the restarting device receives replies from all the helper routers, the restarting device selects routes, 
updates the forwarding table, and discards the old routes. At this point, full OSPF adjacencies are 
reestablished and the restarting device receives and processes OSPF LSAs as usual. When the helper 
routers no longer receive grace LSAs from the restarting device or when the topology of the network 
changes, the helper routers also resume normal operation. 


Beginning with Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPFv2 
graceful restart configurations. The Junos OS implementation is based on RFC 4811, OSPF Out-of-Band 
Link State Database (LSDB) Resynchronization, RFC 4812, OSPF Restart Signaling, and RFC 4813, OSPF 
Link-Local Signaling. In restart signaling-based helper mode implementations, the restarting device informs 
its restart status to its neighbors only after the restart is complete. When the restart is complete, the 
restarting device sends hello messages to its helper routers with the restart signal (RS) bit set in the hello 
packet header. When a helper router receives a hello packet with the RS bit set in the header, the helper 
router returns a hello message to the restarting device. The reply hello message from the helper router 
contains the ResyncState flag and the ResyncTimeout timer that enable the restarting device to keep track 
of the helper routers that are syncing up with it. When all helpers complete the synchronization, the 
restarting device exits the restart mode. 


NOTE: Restart signaling-based graceful restart helper mode is not supported for OSPFv3 
configurations. 
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Planned and Unplanned Graceful Restart 


OSPF supports two types of graceful restart: planned and unplanned. During a planned restart, the restarting 
routing device informs the neighbors before restarting. The neighbors act as if the routing device is still 
within the network topology, and continue forwarding traffic to the restarting routing device. A grace 
period is set to specify when the neighbors should consider the restarting routing device as part of the 
topology. During an unplanned restart, the routing device restarts without warning. 


Example: Configuring Graceful Restart for OSPF 


IN THIS SECTION 


Requirements | 309 
Overview | 309 
Configuration | 310 


Verification | 314 


This example shows how to configure graceful restart specifically for OSPF. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71. 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 
Overview 


Graceful restart enables a routing device undergoing a restart to inform its adjacent neighbors and peers 
of its condition. During a graceful restart, the restarting routing device and its neighbors continue forwarding 


packets without disrupting network performance. By default, graceful restart is disabled. You can globally 
enable graceful restart for all routing protocols by including the graceful-restart statement at the [edit 
routing-options] hierarchy level, or you can enable graceful restart specifically for OSPF by including the 
graceful-restart statement at the [edit protocols (ospflospf3)] hierarchy level. 


The first example shows how to enable graceful restart and configure the optional settings for the grace 
period interval. In this example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPF area 0.0.0.0, and you 
configure those interfaces for graceful restart. The grace period interval for OSPF graceful restart is 
determined as equal to or less than the sum of the notify-duration time interval and the restart-duration 
time interval. The grace period is the number of seconds that the routing device’s neighbors continue to 
advertise the routing device as fully adjacent, regardless of the connection state between the routing 
device and its neighbors. 


The notify-duration statement configures how long (in seconds) the routing device notifies helper routers 
that it has completed graceful restart by sending purged grace link-state advertisements (LSAs) over all 
interfaces. By default, the routing device sends grace LSAs for 30 seconds. The range is from 1 through 
3600 seconds. 


The restart-duration statement configures the amount of time the routing device waits (in seconds) to 
complete reacquisition of OSPF neighbors from each area. By default, the routing device allows 180 
seconds. The range is from 1 through 3600 seconds. 


The second example shows how to disable graceful restart for OSPF by including the disable statement. 


Configuration 


IN THIS SECTION 


@ Enabling Graceful Restart for OSPF | 310 
@ Disabling Graceful Restart for OSPF | 313 


Enabling Graceful Restart for OSPF 


CLI Quick Configuration 


To quickly enable graceful restart for OSPF, copy the following commands and paste them into the CLI. 


[edit] 

set interfaces fe-1/1/1 unit O family inet address 10.0.0.4 
set interfaces fe-1/1/2 unit O family inet address 10.0.0.5 
set protocols ospf area 0.0.0.0 interface fe-1/1/1 
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set protocols ospf area 0.0.0.0 interface fe-1/1/2 

set routing-options graceful-restart 

set protocols ospf graceful-restart restart-duration 190 
set protocols ospf graceful-restart notify-duration 40 


Step-by-Step Procedure 
To enable graceful restart for OSPF: 


1. Configure the interfaces. 


NOTE: For OSPFv3, use IPv6 addresses. 


[edit] 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5 


2. Configure OSPF on the interfaces. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2 


3. Configure graceful restart globally 


[edit] 
user@host#edit routing-options graceful-restart 


4. Configure OSPF graceful restart. 


[edit] 
user@host# edit protocols ospf graceful-restart 
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5. (Optional) Configure the restart duration time. 


[edit protocols ospf graceful-restart] 
user@host# set restart-duration 190 


6. (Optional) Configure the notify duration time. 


[edit protocols ospf graceful-restart] 
user@host# set notify-duration 40 


7. \f you are done configuring the device, commit the configuration. 


[edit protocols ospf graceful-restart] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and show protocols ospf commands. If the 
output does not display the intended configuration, repeat the instructions in this example to correct the 
configuration. 


user@host# show interfaces 
fe-1/1/1 { 
unit O { 
family inet { 
address 10.0.0.4/32; 


} 
fe-1/1/2 { 
unit O { 
family inet { 
address 10.0.0.5/32; 


} 

user@host# show protocols ospf 

graceful-restart { 
restart-duration 190; 
notify-duration 40; 

} 

area 0.0.0.0 { 
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interface fe-1/1/1.0; 
interface fe-1/1/2.0, 


To confirm an OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands. 


Disabling Graceful Restart for OSPF 


CLI Quick Configuration 


To quickly disable graceful restart for OSPF, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configuration, copy and paste 
the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


[edit] 
user@host# set protocols ospf graceful-restart disable 


Step-by-Step Procedure 
To disable graceful restart for OSPF: 


1. Disable graceful restart for the OSPF protocol only. 


This command does not affect the global graceful restart configuration setting. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf graceful-restart disable 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 


graceful-restart disable; 


To confirm an OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


IN THIS SECTION 


@ = Verifying the OSPF Graceful Restart Configuration | 314 
@ Verifying Graceful Restart Status | 314 


Confirm that the configuration is working properly. 


Verifying the OSPF Graceful Restart Configuration 


Purpose 


Verify information about your OSPF graceful restart configuration. 


Action 


From operational mode, enter the show ospf overview command for OSPFv2. Enter the show ospf3 
overview command for OSPFv3. 


Meaning 


The Restart field displays the status of graceful restart as either enabled or disabled. The Restart duration 
field displays how much time the restarted routing device requires to complete reacquisition of OSPF 
neighbors. The Restart grace period field displays how much time the neighbors should consider the 
restarted routing device as part of the topology. 


Verifying Graceful Restart Status 


Purpose 


Verify the status of graceful restart. 


Action 


From operational mode, enter the show route instance detail command. 


Meaning 

The Restart State field displays Pending if the restart has not been completed or Complete if the restart 
has finished. The Path selection timeout field indicates the amount of time remaining until graceful restart 
is declared complete. There is a more detailed Restart State field that displays a list of protocols that have 
or have not yet completed graceful restart for the specified routing table. 
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Example: Configuring the Helper Capability Mode for OSPFv2 Graceful 
Restart 


IN THIS SECTION 


Requirements | 315 
Overview | 315 
Configuration | 316 
Verification | 319 


This example shows how to disable and reenable the helper mode capability for OSPFv2 graceful restart. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election’ 


) 


on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 


page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


The OSPF graceful restart helper capability assists a neighboring routing device attempting a graceful 

restart. By default, the helper capability is globally enabled when you start the routing platform. This means 
that the helper capability is enabled when you start OSPF, even if graceful restart is not globally enabled 
or specifically enabled for OSPF. You can further modify your graceful restart configuration to disable the 


helper capability. 


Beginning with Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPFv2 


graceful restart configurations. Both the standard and restart signaling-based helper modes are enabled 
by default. 
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In the first example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPF v2 area 0.0.0.0, and you configure those 
interfaces for graceful restart. You then disable the standard OSPF v2 graceful restart helper capability by 
including the helper-disable standard statement. This configuration is useful if you have an environment 
that contains other vendor equipment that is configured for restart signaling-based graceful restart. 


NOTE: The helper-disable statement and the no-strict-lsa-checking statement cannot be 
configured at the same time. If you attempt to configure both statements at the same time, the 
routing device displays a warning message when you enter the show protocols ospf command. 


The second example shows how to reenable the standard OSPF v2 restart helper capability that you disabled 


in the first example. 


Configuration 


IN THIS SECTION 


@ Disabling Helper Mode for OSPFv2 | 316 
@ ~~ Reenabling Helper Mode for OSPFv2 | 318 


Disabling Helper Mode for OSPFv2 


CLI Quick Configuration 
To quickly enable graceful restart for OSPFv2 with helper mode disabled, copy the following commands 
and paste them into the CLI. 


[edit] 

set interfaces fe-1/1/1 unit O family inet address 10.0.0.4 
set interfaces fe-1/1/2 unit O family inet address 10.0.0.5 
set protocols ospf area 0.0.0.0 interface fe-1/1/1 

set protocols ospf area 0.0.0.0 interface fe-1/1/2 

set protocols ospf graceful-restart helper-disable standard 


Step-by-Step Procedure 
To enable graceful restart for OSPFv2 with helper mode disabled: 


1. Configure the interfaces. 
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[edit] 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5 


2. Configure OSPFv2 on the interfaces 


[edit] 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2 


3. Disable the OSPFv2 graceful restart helper capability. 
If you disable the OSPFv2 graceful restart helper capability, you cannot disable strict LSA checking. 


[edit] 
user@host# set protocols ospf graceful-restart helper-disable standard 


4. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
fe-1/1/1 { 
unit O { 
family inet { 
address 10.0.0.4/32; 


} 
fe-1/1/2 { 
unit O { 
family inet { 
address 10.0.0.5/32; 


} 
user@host# show protocols ospf 
graceful-restart { 
helper-disable { 
standard; 


} 

area 0.0.0.0 { 
interface fe-1/1/1.0; 
interface fe-1/1/2.0; 


Reenabling Helper Mode for OSPFv2 


CLI Quick Configuration 


To quickly reenable standard helper-mode for OSPFv2, copy the following commands, paste them into a 
text file, remove any line breaks, change any details necessary to match your network configuration, copy 
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration 
mode. 


[edit] 
delete protocols ospf graceful-restart helper-disable standard 


NOTE: To reenable restart signaling-based helper mode, include the restart-signaling statement. 
To reenable both standard and restart signaling-based helper mode, include the both statement. 


Step-by-Step Procedure 
To reenable standard helper mode for OSPFv2: 


1. Delete the standard helper-mode statement from the OSPFv2 configuration. 


[edit] 
user@host# delete protocols ospf graceful-restart helper-disable standard 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 
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Results 


After you reenable standard helper mode, the show protocols ospf command no longer displays the graceful 
restart configuration. 


Verification 


IN THIS SECTION 


@ = Verifying the OSPFv2 Graceful Restart Configuration | 319 
@ Verifying Graceful Restart Status | 319 


Confirm that the configuration is working properly. 


Verifying the OSPFv2 Graceful Restart Configuration 


Purpose 


Verify information about your OSPFv2 graceful restart configuration. The Restart field displays the status 
of graceful restart as either enabled or disabled, the Graceful restart helper mode field displays the status 
of the standard helper mode capability as enabled or disabled, and the Restart-signaling helper mode field 
displays the status of the restart signaling-based helper mode as enabled or disabled. By default, both 
standard and restart signaling-based helper modes are enabled. 


Action 


From operational mode, enter the show ospf overview command. 


Verifying Graceful Restart Status 


Purpose 

Verify the status of graceful restart. The Restart State field displays Pending if the restart has not completed, 
or Complete if the restart has finished. The Path selection timeout field indicates the amount of time 
remaining until graceful restart is declared complete. There is a more detailed Restart State field that 
displays a list of protocols that have completed graceful restart or have not yet completed graceful restart 
for the specified routing table. 


Action 


From operational mode, enter the show route instance detail command. 
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Example: Configuring the Helper Capability Mode for OSPFv3 Graceful 
Restart 


IN THIS SECTION 


Requirements | 320 
Overview | 320 
Configuration | 321 


Verification | 323 


This example shows how to disable and reenable the helper mode capability for OSPFv3 graceful restart. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


e Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


The OSPF graceful restart helper capability assists a neighboring routing device attempting a graceful 
restart. By default, the helper capability is globally enabled when you start the routing platform. This means 
that the helper capability is enabled when you start OSPF, even if graceful restart is not globally enabled 
or specifically enabled for OSPF. You can further modify your graceful restart configuration to disable the 
helper capability. 


In the first example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPFv3 area 0.0.0.0, and you configure those 
interfaces for graceful restart. You then disable the OSPFv3 graceful restart helper capability by including 
the helper-disable statement. 
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NOTE: The helper-disable statement and the no-strict-lsa-checking statement cannot be 
configured at the same time. If you attempt to configure both statements at the same time, the 
routing device displays a warning message when you enter the show protocols ospf command. 


The second example shows how to reenable the OSPFv8 restart helper capability that you disabled in the 
first example. 


Configuration 


IN THIS SECTION 


@ Disabling Helper Mode for OSPFv3 | 321 
@ _Reenabling Helper Mode for OSPFv3 | 323 


Disabling Helper Mode for OSPFv3 


CLI Quick Configuration 
To quickly enable graceful restart for OSPFv3 with helper mode disabled, copy the following commands 
and paste them into the CLI. 


[edit] 

set interfaces fe-1/1/1 unit O family inet6 address 2001:0a00:0004:: 
set interfaces fe-1/1/2 unit O family inet6 address 2001:0a00:0005:: 
set protocols ospf3 area 0.0.0.0 interface fe-1/1/1 

set protocols ospf3 area 0.0.0.0 interface fe-1/1/2 

set protocols ospf3 graceful-restart helper-disable 


Step-by-Step Procedure 
To enable graceful restart for OSPFv3 with helper mode disabled: 


1. Configure the interfaces. 
[edit] 


user@host# set interfaces fe-1/1/1 unit 0 family inet6 address 2001:0a00:0004:: 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 2001:0a00:0005:: 


2. Configure OSPFv3 on the interfaces 


322 


[edit] 
user@host# set protocols ospf3 area 0.0.0.0 interface fe-1/1/1 
user@host# set protocols ospf3 area 0.0.0.0 interface fe-1/1/2 


3. Disable the OSPFv3 graceful restart helper capability. 
If you disable the OSPFv3 graceful restart helper capability, you cannot disable strict LSA checking. 


[edit] 
user@host# set protocols ospf3 graceful-restart helper-disable 


4. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces and the show protocols ospf3 commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
fe-1/1/1 { 
unit O { 
family ineté { 
address 2001:0a00:0004::/128; 


} 
fe-1/1/2 { 
unit O { 
family ineté { 
address 2001:0a00:0005::/128; 


} 
user@host# show protocols ospf3 
graceful-restart { 
helper-disable; 
} 
area 0.0.0.0 { 
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interface fe-1/1/1.0,; 
interface fe-1/1/2.0, 


Reenabling Helper Mode for OSPFv3 
CLI Quick Configuration 


To quickly reenable helper-mode for OSPFv3, copy the following command and paste it into the CLI. 


[edit] 
delete protocols ospf3 graceful-restart helper-disable 


Step-by-Step Procedure 
To reenable helper mode for OSPFv3: 


1. Delete the standard helper-mode statement from the OSPFv3 configuration. 


[edit] 
user@host# delete protocols ospf3 graceful-restart helper-disable 


2. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


After you reenable standard helper mode, the show protocols ospfs command no longer displays the 
graceful restart configuration. 


Verification 


IN THIS SECTION 


@ = Verifying the OSPFv3 Graceful Restart Configuration | 324 
@ Verifying Graceful Restart Status | 324 


Confirm that the configuration is working properly. 
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Verifying the OSPFv3 Graceful Restart Configuration 


Purpose 


Verify information about your OSPFv3 graceful restart configuration. The Restart field displays the status 
of graceful restart as either enabled or disabled, and the Helper mode field displays the status of the helper 
mode capability as either enabled or disabled. 


Action 


From operational mode, enter the show ospf3 overview command. 


Verifying Graceful Restart Status 


Purpose 

Verify the status of graceful restart. The Restart State field displays Pending if the restart has not completed, 
or Complete if the restart has finished. The Path selection timeout field indicates the amount of time 
remaining until graceful restart is declared complete. There is a more detailed Restart State field that 
displays a list of protocols that have completed graceful restart or have not yet completed graceful restart 
for the specified routing table. 


Action 


From operational mode, enter the show route instance detail command. 


| Example: Disabling Strict LSA Checking for OSPF Graceful Restart 


IN THIS SECTION 


Requirements | 324 
Overview | 325 
Configuration | 325 


Verification | 327 


This example shows how to disable strict link-state advertisement (LSA) checking for OSPF graceful restart. 


Requirements 


Before you begin: 
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Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


You can disable strict LSA checking to prevent the termination of graceful restart by a helping router. You 
might configure this option for interoperability with other vendor devices. The OSPF graceful restart helper 
capability must be enabled if you disable strict LSA checking. By default, LSA checking is enabled. 


In this example, interfaces fe-1/1/1 and fe-1/1/2 are in OSPF area 0.0.0.0, and you configure those 
interfaces for graceful restart. You then disable strict LSA checking by including the no-strict-lsa-checking 
statement. 


NOTE: The helper-disable statement and the no-strict-lsa-checking statement cannot be 
configured at the same time. If you attempt to configure both statements at the same time, the 
routing device displays a warning message when you enter the show protocols ospf command. 


Configuration 


CLI Quick Configuration 


To quickly enable graceful restart for OSPF with strict LSA checking disabled, copy the following commands 
and paste them into the CLI. 


[edit] 

set interfaces fe-1/1/1 unit O family inet address 10.0.0.4 
set interfaces fe-1/1/2 unit O family inet address 10.0.0.5 
set protocols ospf area 0.0.0.0 interface fe-1/1/1 

set protocols ospf area 0.0.0.0 interface fe-1/1/2 

set protocols ospf graceful-restart no-strict-lsa-checking 


Step-by-Step Procedure 
To enable graceful restart for OSPF with strict LSA checking disabled: 


1. Configure the interfaces. 
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NOTE: For OSPFv3, use IPvé6 addresses. 


[edit] 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.4 
user@host# set interfaces fe-1/1/1 unit 0 family inet address 10.0.0.5 


2. Configure OSPF on the interfaces 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/1 
user@host# set protocols ospf area 0.0.0.0 interface fe-1/1/2 


3. Disable strict LSA checking. 
If you disable the strict LSA checking, OSPF graceful restart helper capability must be enabled (which 
is the default behavior). 


[edit] 
user@host# set protocols ospf graceful-restart no-strict-lsa-checking 


4. If you are done configuring the device, commit the configuration. 


[edit ] 
user@host# commit 


Results 

Confirm your configuration by entering the show interfaces and the show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show interfaces 
fe-1/1/1 { 
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unit O { 
family inet { 
address 10.0.0.4/32; 


} 
fe-1/1/2 { 
unit O { 
family inet { 
address 10.0.0.5/32; 


} 
user@host# show protocols ospf 
graceful-restart { 
no-strict-lsa-checking; 
} 
area 0.0.0.0 { 
interface fe-1/1/1.0; 
interface fe-1/1/2.0, 


To confirm your OSPFv3 configuration, enter the show interfaces and the show protocols ospf3 commands. 


Verification 


IN THIS SECTION 


@ Verifying the OSPF Graceful Restart Configuration | 327 
@ Verifying Graceful Restart Status | 328 


Confirm that the configuration is working properly. 


Verifying the OSPF Graceful Restart Configuration 


Purpose 
Verify information about your OSPF graceful restart configuration. The Restart field displays the status 
of graceful restart as either enabled or disabled. 


Action 
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From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview command for OSPFv3. 


Verifying Graceful Restart Status 


Purpose 


Verify the status of graceful restart. The Restart State field displays Pending if the restart has not completed, 
or Complete if the restart has finished. The Path selection timeout field indicates the amount of time 
remaining until graceful restart is declared complete. There is a more detailed Restart State field that 
displays a list of protocols that have completed graceful restart or have not yet completed graceful restart 
for the specified routing table. 


Action 


From operational mode, enter the show route instance detail command. 
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Configuring Loop-Free Alternate Routes for OSPF 


IN THIS SECTION 


Per Prefix Loop Free Alternates for OSPF | 330 

Configuring Per-Prefix LFA for OSPF | 331 

Loop-Free Alternate Routes for OSPF Overview | 332 

Configuring Link Protection for OSPF | 333 

Configuring Node-Link Protection for OSPF | 335 

Configuring Node to Link Protection Fallback for OSPF | 336 

Excluding an OSPF Interface as a Backup for a Protected Interface | 337 
Configuring Backup SPF Options for Protected OSPF Interfaces | 338 
Configuring RSVP Label-Switched Paths as Backup Paths for OSPF | 340 
Example: Configuring Loop-Free Alternate Routes for OSPF | 341 
Remote LFA over LDP Tunnels in OSPF Networks Overview | 368 
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 369 


Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 371 


| Per Prefix Loop Free Alternates for OSPF 


In certain topologies and usage scenarios, when multiple destinations originate the same prefix and there 
is no viable LFA to the best prefix originator, whilst a non-best prefix originator has one. Per-prefix LFA is 
a technology by which, the LFA to a non-best prefix originator can be used in lieu of the LFA to the best 
prefix originator to provide local repair. This can be used to increase the local repair coverage for the OSPF 
protocol also. 


Per-Prefix Loop Free Alternates (LFA)—Loop Free Alternates (LFA) is a technology by which a neighbor 
can be used as a backup next hop to provide a local repair path for the traffic to flow temporarily in case 
of failures in the primary next hop (node or link). For this, the basic requirement is that the selected backup 
neighbor provides a loop free path with respect to primary next hop towards a destination, originating a 
set of interior gateway protocol (IGP) prefixes. 


The following topology explains the deployment case where per prefix LFA feature is applicable. 
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Figure 21: Per-Prefix LFA Usage Scenario 
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ABR1 and ABR2 are area boundary routers (ABRs), dual homed to an IPvé6 core network, which advertises 
the summary LSA for the prefix 10.0.1.0/24 with a metric of 10. Also, from PE router's perspective, ABR1 
is the best prefix originator for 10.0.1.0/24. In this case, P2 is not a valid LFA for ABR1 because of the 
equal cost multi paths (ECMP) {P2, PE, P1, ABR1} and {P2, ABR2, ABR1} causing some of the traffic to be 
looped back through the router PE (no valid LFA). However for ABR2, which is also a prefix originator for 
10.0.1.0/24, P2 is a valid LFA because the only path is {P2, ABR2}. 


SEE ALSO 


| per-prefix-calculation | 717 


| Configuring Per-Prefix LFA for OSPF 


Per prefix LFA is a mechanism by which LFA to a non-best prefix originator can be used in lieu of the LFA 
to the best prefix originator to provide local repair. In such cases, per prefix LFA can be used to increase 
the local repair coverage for the OSPF protocol. 


Loop Free Alternates (LFA) is a mechanism by which a neighbor can be used as a backup next hop to 
provide a local repair path for the traffic to flow temporarily in case of failures in the primary next hop 
(node or link). For this the basic requirement is that the selected backup neighbor provides a loop free 
path with respect to primary next hop towards a destination originating a set of IGP prefixes. In certain 
topologies and usage scenarios, it may be possible that multiple destinations are originating the same prefix 
and there is no viable LFA to the best prefix originator, whilst a non-best prefix originator has one. Per 
prefix LFA is a mechanism by which LFA to a non-best prefix originator can be used in lieu of the LFA to 
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the best prefix originator to provide local repair. In such cases, per prefix LFA can be used to increase the 
local repair coverage for the OSPF protocol. 


To configure per prefix LFA for an OSPF interface: 


e Configure the per-prefix-calculation configuration statement at the [edit protocols (ospf | ospf3) 
backup-spf-options] hierarchy level. 


SEE ALSO 


| per-prefix-calculation | 717 


Loop-Free Alternate Routes for OSPF Overview 


Support for OSPF loop-free alternate routes essentially adds IP fast-reroute capability for OSPF. Junos 
OS precomputes loop-free backup routes for all OSPF routes. These backup routes are preinstalled in the 
Packet Forwarding Engine, which performs a local repair and implements the backup path when the link 
for a primary next hop for a particular route is no longer available. With local repair, the Packet Forwarding 
Engine can correct a path failure before it receives precomputed paths from the Routing Engine. Local 
repair reduces the amount of time needed to reroute traffic to less than 50 milliseconds. In contrast, global 
repair can take up to 800 milliseconds to compute a new route. Local repair enables traffic to continue to 
be routed using a backup path until global repair is able to calculate a new route. 


A loop-free path is one that does not forward traffic back through the routing device to reach a given 
destination. That is, a neighbor whose shortest path first to the destination traverses the routing device 
that is not used as a backup route to that destination. To determine loop-free alternate paths for OSPF 
routes, Junos OS runs shortest-path-first (SPF) calculations on each one-hop neighbor. You can enable 
support for alternate loop-free routes on any OSPF interface. Because it is common practice to enable 
LDP on an interface for which OSPF is already enabled, this feature also provides support for LDP 
label-switched paths (LSPs.) 


NOTE: If you enable support for alternate loop-free routes on an interface configured for both 
LDP and OSPF, you can use the traceroute command to trace the active path to the primary 
next hop. 


The level of backup coverage available through OSPF routes depends on the actual network topology and 
is typically less than 100 percent for all destinations on any given routing device. You can extend backup 
coverage to include RSVP LSP paths. 


Junos OS provides three mechanisms for route redundancy for OSPF through alternate loop-free routes: 


Link protection—Offers per-link traffic protection. Use link protection when you assume that only a 
single link might become unavailable but that the neighboring node on the primary path would still be 
available through another interface. 


Node-link protection—Establishes an alternate path through a different routing device altogether. Use 
node-link protection when you assume that access to a node is lost when a link is no longer available. 
As aresult, Junos OS calculates a backup path that avoids the primary next-hop routing device. 


Per-prefix loop-free alternates (LFAs)—It is a technology by which a neighbor can be used as a backup 
next hop to provide a local repair path for the traffic to flow temporarily in case of failures in the primary 
next hop (node or link). For this, the basic requirement is that the selected backup neighbor provides a 
loop-free path with respect to a primary next hop towards a destination, originating a set of interior 
gateway protocol (IGP) prefixes. 


In certain topologies and usage scenarios, it may be possible that multiple destinations are originating 
the same prefix and there is no viable LFA to the best prefix originator, while a non-best prefix originator 
has a viable LFA. Per-prefix LFA is a mechanism by which LFA to a non-best prefix originator can be used 
in lieu of the LFA to the best prefix originator to provide local repair. In such cases, per prefix LFA can 
be used to increase the local repair coverage for the OSPF protocol. 


When you enable link protection or node-link protection on an OSPF interface, Junos OS creates an 


alternate path to the primary next hop for all destination routes that traverse a protected interface. 


Configuring Link Protection for OSPF 


You can configure link protection for any interface for which OSPF is enabled. When you enable link 
protection, Junos OS creates an alternate path to the primary next hop for all destination routes that 


traverse a protected interface. Use link protection when you assume that only a single link might become 


unavailable but that the neighboring node would still be available through another interface. 


Link protection is supported on: 


OSPFv2 and OSPFv3 interfaces 

OSPFv3 unicast realms 

OSPFv2 unicast topologies, except for multicast topologies 
All routing instances supported by OSPFv2 and OSPFv3 


Logical systems 
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To configure link protection for an OSPF interface: 


e Include the link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface 


interface-name] hierarchy level. 


BEST PRACTICE: When you configure link protection for OSPF, you must also configure a 
per-packet load-balancing routing policy to ensure that the routing protocol process installs all 
the next hops for a given route in the routing table. 


In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for link protection. 
If a link for a destination route that traverses this interface becomes unavailable, Junos OS creates a 
loop-free backup path through another interface on the neighboring node, thus avoiding the link that is 
no longer available. 


[edit] 
protocols { 
ospf { 
area 0.0.0.0 { 
interface so-0/0/0.0 { 
link-protection; 


SEE ALSO 


link-protection | 676 
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| Configuring Node-Link Protection for OSPF 


You can configure node-link protection on any interface for which OSPF is enabled. Node-link protection 
establishes an alternative path through a different routing device altogether for all destination routes that 
traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has 
failed. Junos OS therefore calculates a backup path that avoids the primary next-hop routing device. 


Node-link protection is supported on: 


e OSPFv2 and OSPF v3 interfaces 

e OSPFv3 unicast realms 

e OSPFv2 unicast topologies 

e All routing instances supported by OSPFv2 and OSPFv3 


e Logical systems 
To configure node-link protection for an OSPF interface: 


e Include the node-link-protection statement at the [edit protocols (ospf | ospf3) area area-id interface 
interface-name] hierarchy level. 


BEST PRACTICE: You must also configure a per-packet load-balancing routing policy to ensure 
that the routing protocol process installs all the next hops for a given route in the routing table. 


In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for node-link 
protection. If a link for a destination route that traverses this interface becomes unavailable, Junos OS 
creates a loop-free backup path through a different routing device altogether, thus avoiding the primary 
next-hop routing device. 


[edit] 
protocols { 
ospf { 
area 0.0.0.0 { 
interface so-0/0/0.0 { 
node-link-protection; 
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SEE ALSO 


| node-link-protection | 705 


Configuring Node to Link Protection Fallback for OSPF 


You can configure link protection for any interface for which OSPF is enabled. When you enable link 
protection, Junos OS creates an alternate path to the primary next hop for all destination routes that 
traverse a protected interface. Use link protection when you assume that only a single link might become 
unavailable but that the neighboring node would still be available through another interface. 


You can configure node-link protection on any interface for which OSPF is enabled. Node-link protection 
establishes an alternative path through a different routing device altogether for all destination routes that 
traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has 
failed. Junos OS therefore calculates a backup path that avoids the primary next-hop routing device. 


In certain topologies it may be desirable to have local repair protection to node failures in the primary next 
hop, which may not be available. In that case, to ensure that some level of local repair capabilities exist, a 
fallback mechanism is required. Since the link protection is less stringent than node protection, it may be 
possible that link protection exists and provide the same to those destination (and hence the prefixes 
originated by it). 


To configure node to link protection fallback for an OSPF interface: 


e Include the node-link-degradation statement at the [edit protocols (ospf | ospf3) backup-spf-options] 
hierarchy level. 


SEE ALSO 


link-protection | 676 
node-link-protection | 705 
node-link-degradation | 704 
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| Excluding an OSPF Interface as a Backup for a Protected Interface 


By default, all OSPF interfaces that belong to the default instance or to a specific routing instance are 
eligible as a backup interface for interfaces configured with link-protection or node-link protection. You 
can specify that any OSPF interface be excluded from functioning as a backup interface to protected 


interfaces. 
To exclude an OSPF interface as a backup interface for a protected interface: 


e Include the no-eligible-backup statement at the [edit protocols (ospf | ospf3) area area-id interface 
interface-name] hierarchy level. 


In the following example, interface so-0/0/0.0 has been configured to prohibit backup traffic for traffic 
destined for a protected interface. This means that if a neighboring next-hop path or node for a protected 
interface fails, interface so-0/0/0.0 cannot be used to transmit traffic to a backup path. 


[edit] 
protocols { 
ospf { 
area 0.0.0.0 { 
interface so-0/0/0.0 { 
no-eligible-backup; 


} 


SEE ALSO 


no-eligible-backup | 695 
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| Configuring Backup SPF Options for Protected OSPF Interfaces 


By default, if at least one OSPF interface is configured for link-protection or node-link protection, Junos 
OS calculates backup next hops for all the topologies in an OSPF instance. You can configure the following 
backup shortest-path-first (SPF) options to override the default behavior: 


e Disable the calculation of backup next hops for an OSPF instance or a specific topology in an instance. 


e Prevent the installation of backup next hops in the routing table or the forwarding table for an OSPF 
instance or a specific topology in an instance. 


e Limit the calculation of backup next hops to a subset of paths as defined in RFC 5286, Basic Specification 
for IP Fast Reroute: Loop-Free Alternates. 


You can disable the backup SPF algorithm for an OSPF instance or specific topology in an instance. Doing 
so prevents the calculation of backup next hops for that OSPF instance or topology. 


To disable the calculation of backup next hops for an OSPF instance or topology: 


e Include the disable statement at the [edit protocols (ospf | ospf3) backup-spf-options] or [edit protocols 
ospf backup-spf-options topology topology-name] hierarchy level. 


In the following example, the calculation of backup next hops is disabled for the OSPF topology voice: 


[edit] 
protocols { 
ospf { 
topology voice { 
backup-spf-options { 
disable; 


You can configure the routing device to prevent the installation of backup next hops in the routing table 
or the forwarding table for an OSPF instance, or a specific topology in an OSPF instance. The SPF algorithm 
continues to calculate backup next hops, but they are not installed. 


To prevent the routing device from installing backup next hops in the routing table or the forwarding table: 


e Include the no-install statement at the [edit protocols (ospf | ospf3) backup-spf-options] or the [edit 
protocols ospf topology topology-name] hierarchy level. 


In the following example, backup next hops for the OSPF topology voice are not installed in the routing 
table or forwarding table. Any calculated backup next hops for other OSPF instances or topologies continue 
to be installed. 
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[edit] 
protocols { 
ospf { 
topology voice { 
backup-spf-options { 
no-install; 


You can limit the calculation of backup next hops to downstream paths, as defined in RFC 5286. You can 
specify for Junos OS to use only downstream paths as backup next hops for protected interfaces for an 
OSPF instance or a specific topology in an OSPF instance. In a downstream path, the distance from the 
backup neighbor to the destination must be smaller than the distance from the calculating routing device 
to the destination. Using only downstream paths as loop-free alternate paths for protected interfaces 
ensures that these paths do not result in microloops. However, you might experience less than optimal 
backup coverage for your network. 


To limit the calculation of backup next hops to downstream paths: 


e Include the downstream-paths-only statement at the [edit protocols (ospf | ospf3) backup-spf-options] 
or [edit protocols ospf backup-spf-options topology topology-name] hierarchy level. 


In the following example, only downstream paths are calculated as backup next hops for the topology 
voice: 


[edit] 
protocols { 
ospf { 
topology voice { 
backup-spf-options { 
downstream-paths-only; 


SEE ALSO 


backup-spf-options | 618 
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| Configuring RSVP Label-Switched Paths as Backup Paths for OSPF 


When configuring an OSPF interface for link protection or node-link protection, relying on the 
shortest-path-first (SPF) calculation of backup paths for one-hop neighbors might result in less than 100 
percent backup coverage for a specific network topology. You can enhance coverage of OSPF and LDP 
label-switched-paths (LSPs) by configuring RSVP LSPs as backup paths. 


When configuring an LSP, you must specify the IP address of the egress router. 


NOTE: RSVP LSPs can be used as backup paths only for the default topology for OSPFv2 and 
not for a configured topology. Additionally, RSVP LSP cannot be used a backup paths for 
non-default instances for OSPFv2 or OSPFv3. 


To configure a specific RSVP LSP as a backup path: 


1. Include the backup statement at the [edit protocols mpls labeled-switched-path Isp-name] hierarchy 
level. 


2. Specify the address of the egress router by including the to ip-address statement at the [edit protocols 
mpls label-switched-path] hierarchy level. 


In the following example, the RSVP LSP f-to-g is configured as a backup LSP for protected OSPF interfaces. 
The egress router is configured with the IP address 192.168.1.4. 


[edit] 
protocols { 
mpls { 
label-switched-path f-to-g { 
to 192.168.1.4; 
backup; 
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| Example: Configuring Loop-Free Alternate Routes for OSPF 


IN THIS SECTION 


Requirements | 341 
Overview | 341 
Configuration | 342 


Verification | 353 


This example demonstrates the use of link protection for interfaces that have OSPF enabled. 


When you enable link protection, Junos OS creates an alternate path to the primary next hop for all 
destination routes that traverse a protected interface. Use link protection when you assume that only a 
single link might become unavailable but that the neighboring node would still be available through another 
interface. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


In this example, six OSPF neighbors are configured with link protection. This causes Junos OS to create 
an alternate path to the primary next hop for all destination routes that traverse each protected interface. 
Link protection is used here because even if a link becomes unavailable, the neighboring node would still 
be available through another interface. 


The example shows two topologies. One is the default topology, and the other is the voice topology. For 
more information about multitopology routing, see the Multitopology Routing User Guide. 


The example also includes RSVP LSPs configured as backup LSPs for protected OSPF interfaces. 


Topology 


Figure 22 on page 342 shows the sample network. 
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Figure 22: OSPF Link Protection 
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“CLI Quick Configuration” on page 342 shows the configuration for all of the devices in Figure 22 on page 342. 


The section “Step-by-Step Procedure” on page 348 describes the steps on Device R11. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device R1 


set interfaces so-0/2/2 unit 0 description to-R2 

set interfaces so-0/2/2 unit 0 family inet address 192.168.242.1/30 
set interfaces so-0/2/2 unit O family mpls 

set interfaces t1-0/1/2 unit 0 description to-R2 

set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.1/30 
set interfaces t1-0/1/2 unit 0 family mpls 

set interfaces t1-0/1/0 unit 0 description to-R4 

set interfaces t1-0/1/0 unit 0 family inet address 192.168.241.17/30 
set interfaces t1-0/1/0 unit 0 family mpls 

set interfaces so-0/2/0 unit 0 description to-R4 

set interfaces so-0/2/0 unit 0 family inet address 192.168.242.17/30 
set interfaces so-0/2/0 unit O family mpls 
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set interfaces loO unit O family inet address 10.255.164.1/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls label-switched-path path1 backup 

set protocols mpls label-switched-path path1 to 10.255.164.3 

set protocols mpls label-switched-path path2 backup 

set protocols mpls label-switched-path path2 to 10.255.164.3 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set policy-options policy-statement pplb then load-balance per-packet 
set routing-options forwarding-table export pplb 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Device R2 


set interfaces so-0/2/2 unit 0 description to-R1 

set interfaces so-0/2/2 unit O family inet address 192.168.242.2/30 
set interfaces so-0/2/2 unit O family mpls 

set interfaces t1-0/1/2 unit 0 description to-R1 

set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.2/30 
set interfaces t1-0/1/2 unit 0 family mpls 

set interfaces so-0/2/0 unit 0 description to-R5 

set interfaces so-0/2/0 unit O family inet address 192.168.242.21/30 
set interfaces so-0/2/0 unit O family mpls 

set interfaces so-0/2/1 unit 0 description to-R3 
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set interfaces so-0/2/1 unit 0 family inet address 192.168.242.5/30 
set interfaces so-0/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.164.2/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface so-0/2/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/1.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Device R3 


set interfaces t1-0/1/2 unit 0 description to-R6 

set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.25/30 
set interfaces t1-0/1/2 unit 0 family mpls 

set interfaces so-0/2/1 unit 0 description to-R2 

set interfaces so-0/2/1 unit O family inet address 192.168.242.6/30 
set interfaces so-0/2/1 unit 0 family mpls 

set interfaces so-0/2/0 unit 0 description to-R6 

set interfaces so-0/2/0 unit 0 family inet address 192.168.242.25/30 
set interfaces so-0/2/0 unit O family mpls 

set interfaces loO unit 0 family inet address 10.255.164.3/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 
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set protocols ospf traceoptions file ospf 

set protocols ospf traceoptions file size 5m 

set protocols ospf traceoptions file world-readable 

set protocols ospf traceoptions flag error 

set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 5 

set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/1.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set routing-options static route 11.3.1.0/24 discard 

set routing-options static route 11.3.2.0/24 discard 

set routing-options static route 11.3.3.0/24 discard 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Device R4 


set interfaces t1-0/1/0 unit 0 description to-R1 

set interfaces t1-0/1/0 unit 0 family inet address 192.168.241.18/30 
set interfaces t1-0/1/0 unit 0 family mpls 

set interfaces so-0/2/0 unit 0 description to-R1 

set interfaces so-0/2/0 unit O family inet address 192.168.242.18/30 
set interfaces so-0/2/0 unit 0 family mpls 

set interfaces t1-0/1/2 unit 0 description to-R5 

set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.9/30 
set interfaces t1-0/1/2 unit 0 family mpls 

set interfaces so-0/2/2 unit 0 description to-R5 

set interfaces so-0/2/2 unit 0 family inet address 192.168.242.9/30 
set interfaces so-0/2/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.164.4/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 
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set protocols mpls interface fxp0.0 disable 

set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/2.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Device R5 


set interfaces t1-0/1/2 unit 0 description to-R4 

set interfaces t1-0/1/2 unit 0 family inet address 192.168.241.10/30 
set interfaces t1-0/1/2 unit 0 family mpls 

set interfaces sO-0/2/0 unit 0 description to-R2 

set interfaces sO-0/2/0 unit 0 family inet address 192.168.242.22/30 
set interfaces sO-0/2/0 unit O family mpls 

set interfaces so-0/2/2 unit 0 description to-R4 

set interfaces so-0/2/2 unit O family inet address 192.168.242.10/30 
set interfaces so-0/2/2 unit 0 family mpls 

set interfaces so-0/2/1 unit O description to-R6 

set interfaces so-0/2/1 unit O family inet address 192.168.242.13/30 
set interfaces so-0/2/1 unit 0 family mpls 

set interfaces t1-0/2/1 unit 0 description to-R6 

set interfaces t1-0/2/1 unit 0 family inet address 192.168.241.13/30 
set interfaces t1-0/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.164.5/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 
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set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface so-0/2/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/1.0 metric 5 

set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface sO-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface sO-0/2/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface so-0/2/2.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/2.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/2/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/2/1.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Device R6 


set interfaces so-0/2/0 unit 0 description to-R5 

set interfaces so-0/2/0 unit 0 family inet address 192.168.242.14/30 
set interfaces so-0/2/0 unit O family mpls 

set interfaces t1-0/1/0 unit 0 description to-R5 

set interfaces t1-0/1/0 unit 0 family inet address 192.168.241.14/30 
set interfaces t1-0/1/0 unit 0 family mpls 

set interfaces t1-0/1/1 unit 0 description to-R3 

set interfaces t1-0/1/1 unit 0 family inet address 192.168.241.26/30 
set interfaces t1-0/1/1 unit 0 family mpls 

set interfaces so-0/2/1 unit 0 description to-R3 

set interfaces so-0/2/1 unit O family inet address 192.168.242.26/30 
set interfaces so-0/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.164.6/32 primary 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf topology voice topology-id 32 

set protocols ospf traffic-engineering 
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set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface so-0/2/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/1.0 metric 5 

set protocols ospf area 0.0.0.0 interface so-0/2/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface so-0/2/0.0 metric 5 

set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/0.0 metric 10 

set protocols ospf area 0.0.0.0 interface t1-0/1/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface t1-0/1/1.0 metric 10 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set routing-options topologies family inet topology voice 

set routing-options forwarding-table indirect-next-hop-change-acknowledgements 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@R1# set so-0/2/2 unit 0 description to-R2 

user@R1# set so-0/2/2 unit 0 family inet address 192.168.242.1/30 
user@R1# set so-0/2/2 unit O family mpls 

user@R1# set t1-0/1/2 unit 0 description to-R2 

user@R1# set t1-0/1/2 unit 0 family inet address 192.168.241.1/30 
user@R1# set t1-0/1/2 unit 0 family mpls 

user@R1# set t1-0/1/0 unit 0 description to-R4 

user@R1# set t1-0/1/0 unit 0 family inet address 192.168.241.17/30 
user@R1# set t1-0/1/0 unit O family mpls 

user@R1# set so-0/2/0 unit O description to-R4 

user@R1# set so-0/2/0 unit 0 family inet address 192.168.242.17/30 
user@R1# set so-0/2/0 unit 0 family mpls 

user@R1# set loO unit O family inet address 10.255.164.1/32 primary 


2. Extend backup coverage to include RSVP LSP paths. 
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[edit protocols rsvp] 
user@R1# set interface all link-protection 
user@R1# set interface fxp0.0 disable 


3. Enable MPLS on the interfaces, and configure backup LSPs to Device R3. 


[edit protocols mpls] 

user@R1# set interface all 

user@R1# set interface fxp0.0 disable 

user@R1# set label-switched-path path1 backup 
user@R1# set label-switched-path path1 to 10.255.164.3 
user@R1# set label-switched-path path2 backup 
user@R1# set label-switched-path path2 to 10.255.164.3 


4. Configure OSPF connections, link metrics, and link protection. 


[edit protocols ospf] 

user@R1# set traffic-engineering 

[edit protocols ospf area 0.0.0.0] 

user@R1# set interface fxp0.0 disable 

user@R1# set interface lo0.0 passive 

user@R1# set interface so-0/2/0.0 link-protection 
user@R1# set interface so-0/2/0.0 metric 10 
user@R1# set interface so-0/2/2.0 link-protection 
user@R1# set interface so-0/2/2.0 metric 10 
user@R1# set interface t1-0/1/0.0 link-protection 
user@R1# set interface t1-0/1/0.0 metric 10 
user@R1# set interface t1-0/1/2.0 link-protection 
user@R1# set interface t1-0/1/2.0 metric 10 


5. (Optional) Configure a specific OSPF topology for voice traffic. 


[edit protocols ospf] 

user@R1# set topology voice topology-id 32 
[edit routing-options topologies family inet] 
user@R1# set topology voice 


6. Enable LDP on the interfaces. 


[edit protocols Idp] 


user@R1# set interface all 
user@R1# set interface fxp0.0 disable 


7. (Optional) Configure per-packet load balancing. 


[edit policy-options policy-statement pplb] 
user@R1# set then load-balance per-packet 
[edit routing-options forwarding-table] 
user@R1# set export pplb 


8. Configure the routing protocol process (rpd) to request an acknowledgement when creating a new 


forwarding next hop. 


We recommend that the indirect-next-hop-change-acknowledgements statement be configured when 
protection mechanisms are being used. This includes MPLS RSVP protection such as fast reroute (FRR) 
as well as interior gateway protocol (IGP) loop-free alternate (LFA) link or node protection. 


[edit routing-options forwarding-table] 
user@R1# set indirect-next-hop-change-acknowledgements 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R1# show interfaces 
so-0/2/2 { 
unit O { 
description to-R2; 
family inet { 
address 192.168.242.1/30; 
} 


family mpls; 


} 
t1-0/1/2 { 
unit O { 
description to-R2; 
family inet { 
address 192.168.241.1/30, 
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family mpls; 


} 
t1-0/1/0 { 
unit 05 { 
description to-R4; 
family inet { 
address 192.168.241.17/30; 
} 


family mpls; 


} 
so-0/2/0 { 
unit O { 
description to-R4; 
family inet { 
address 192.168.242.17/30; 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.164.1/32 { 
primary; 


user@R1# show protocols 
rsvp { 
interface all { 
link-protection; 
} 
interface fxp0.0 { 
disable; 


} 
mpls { 
label-switched-path path1 { 
backup; 
to 10.255.164.3; 
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} 

label-switched-path path2 { 
backup; 
to 10.255.164.3; 

} 

interface all; 

interface fxp0.0 { 
disable; 


} 
ospf { 
topology voice topology-id 32; 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 
interface 100.0 { 
passive; 
} 
interface so-0/2/0.0 { 
link-protection; 
metric 10; 
} 
interface so-0/2/2.0 { 
link-protection; 
metric 10; 
} 
interface t1-0/1/0.0 { 
link-protection; 
metric 10; 
} 
interface t1-0/1/2.0 { 
link-protection; 
metric 10; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 
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user@R1# show policy-options 
policy-statement pplb { 
then { 
load-balance per-packet; 


user@R1# show routing-options 
forwarding-table { 

export pplb; 

indirect-next-hop-change-acknowledgements; 
} 
topologies { 

family inet { 

topology voice; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Verifying the Routes on Device R1 | 353 
Checking the Backup Coverage | 356 


t 

@ 

@ ~~ Checking the Backup LSPs | 357 

@ ~~ Checking the Backup Neighbors | 358 
e 


Checking the SPF Calculations | 359 


Confirm that the configuration is working properly. 


Verifying the Routes on Device R1 


Purpose 
On Device R1, check the OSPF routes in the routing table. 
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Action 


user@R1> show route protocol ospf 
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mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) 


Meaning 


As expected, Device R1 has multiple potential routes to each destination. 


Checking the Backup Coverage 


Purpose 


On Device R1, use the show (ospf | ospf3) backup coverage command to check the level of backup coverage 


available for all the nodes and prefixes in the network. 


Action 


user@R1> show ospf backup coverage 


Topology default coverage: 


Node Coverage: 
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Area 


CERO Ors0) 


Route Coverage: 


Path Type Covered 


ALE eel 
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lap dL 








le Z 


All 


BoOuLes 





Topology voice coverage: 


Node Coverage: 


Area 


OPOROrs0) 


Route Coverage: 


Path Type Covered 


Intra 
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lade ib 








Ext2 


All 


Checking the Backup LSPs 


Purpose 


On Device R1, use the show (ospf | ospf3) backup Isp command to check LSPs designated as backup routes 


for OSPF routes. 


Action 


Routes 


Covered Total Percent 
Nodes Nodes Covered 
5) & 1O00,00% 

Total Percent 

ROUECSm—ECOvcsced 

18 94.44% 

OMe OORIOO:: 

0 100.00% 

ORO OROO.2 

18 94.44% 





user@R1> show ospf backup Isp 


Covered Total Percent 
Nodes Nodes Covered 
8) SO ORIGO:s 

Total Percent 

Routes Covered 

18 94.44% 

0 100.00% 

0 100.00% 

0 100.00% 

18 94.44% 
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pathl 
Egress: 10.255.164.3, Status: up, Last change: 01:13:48 





TE-metric; 19, Metric: 0 
path2 
Eoress: 10°255.164°3, Status: up, Last change: 01713:48 








TE-metric: 19, Metric: 0 


Checking the Backup Neighbors 


Purpose 


On Device R1, use the show (ospf | ospf3) backup neighbor command to check the neighbors through 
which direct next hops for the backup paths are available. 


Action 


user@R1> show ospf backup neighbors 


Topology default backup neighbors: 
Area 0.0.0.0 backup neighbors: 


IO AdSo 54.4 
Neighbor to Self Metric: 10 
Self to Neighbor Metric: 10 
Direct next-hop: so-0/2/0.0 via 192.168.242.18 
Dileecle mesgeinojes iel-O/1/0,.0 wia 192. 168,241, 18 


10.255 164.2 
Neighbor to Self Metric: 10 
Self to Neighbor Metric: 10 
Diese mMedc—inees so-0/2/2.0 wia 192,168,242 2 
Direct next-hop: t1-0/1/2.0 via 192.168.241.2 


10.255.164.3 (LSP endpoint) 
Neighbor to Self Metric: 20 
Self to Neighbor Metric: 20 
Direct next—-hop: pathl 





Direct next—-hop: path2 


Topology voice backup neighbors: 
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Area 0.0.0.0 backup neighbors: 


10.255.164.4 
Neighbor to Self 
Self to Neighbor 
Direct next-—hop: 


Direct next-—hop: 


10 25514164 .2 
Neighbor to Self 
Self to Neighbor 
Direct next-—hop: 


Direct next—hop: 


Metric: 10 
Metric: 10 
so-0/2/0.0 
fel 0/1/00) 


Metric: 10 
Metric: 10 
so—0/ 2/270 
El=O/1/2 oO 


10.255.164.3 (LSP endpoint) 


Neighbor to Self 
Self to Neighbor 


Direct next-—hop: 





Direct next—hop: 


Metric: 20 
Metric: 20 
pathl 
path2 


Checking the SPF Calculations 


Purpose 


On Device R1, use the show (ospf | ospf3) backup spf detail command to check OSPF shortest-path-first 
(SPF) calculations for backup paths. To limit the output, the voice topology is specified in the command. 


Action 


via 


via 


via 


via 


LZ 
192. 


BOAR: 
192 » 


WS) 
168. 


168. 
168. 


242 


DAs 
241. 


user@R1> show ospf backup spf detail topology voice 


Topology voice results: 


Area 0.0.0.0 results: 


UA 6 UGS) BAL 6 2 


Self to Destination Metric: 
Parent Node: 10.255.164.1 


Primary next—hop: 


Backup next—hop: 
Backup Neighbor: 


Neighbor to Destination Metric: 


el—O/ 1/2 .0 


pathl 


10 255 sd G4. 


10 


3 (LSP endpoint) 
Z0F 


5 ALi} 
241. 


18 


Neighbor to Self Metric: 


20 
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Self to Neighbor Metric: 20, Backup preference: 0x0 

Mieciohe esis 10.255. 154.2 

Eligible, Reason: Contributes backup next-—hop 

Backup Neighbor: 10.255.164.2 

Neighbor to Destination Metric: 10, Neighbor to Self Metric: 
Self to Neighbor Metric: 10, Backup preference: 0x0 

Not evaluated, Reason: Interface is already covered 

Backup Neighbor: 10.255.164.4 





Neighbor to Destination Metric: 20, Neighbor to Self Metric: 
Self to Neighbor Metric: 10, Backup preference: 0x0 
Wieaiele Incense 0). 25S). 64). ib 


Not evaluated, Reason: Interface is already covered 


WVA 6 AOS) 5 AGEL, As) 


Self to Destination Metric: 10 

Parent Node: 10.255.164.1 

Primary next—-hop: t1-0/1/0.0 

Backup next—-hop: so-0/2/0.0 via 192.168.242.18 

Backup Neighbor: 10.255.164.3 (LSP endpoint) 
Neighbor to Destination Metric: 30, Neighbor to Self Metric: 
Self to Neighbor Metric: 20, Backup preference: 0x0 

[race Weems 110.255.1164. i 

treacle Weems 10.255 .164.2 

Track Item: 10.255.164.4 





Not eligible, Reason: Path loops 

Backup Neighbor: 10.255.164.4 

Neighbor to Destination Metric: 10, Neighbor to Self Metric: 
Self to Neighbor Metric: 10, Backup preference: 0x0 
Eligible, Reason: Contributes backup next-—hop 

Backup Neighbor: 10.255.164.2 





Neighbor to Destination Metric: 20, Neighbor to Self Metric: 
Self to Neighbor Metric: 10, Backup preference: 0x0 
wieeele Weems 10,255, 164. i 


Not evaluated, Reason: Interface is already covered 


WY 5 LOS), 24 


Self to Destination Metric: 10 

Parent Node: 10.255.164.1 

Primary next—-hop: so-0/2/2.0 

Backup next-—hop: path2 

Backup Neighbor: 10.255.164.3 (LSP endpoint) 
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 
Self to Neighbor Metric: 20, Backup preference: 0x0 
Weeehke Wtems 10,255. 164.2 
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10 


LO) 


20 


10 


10 


20 


Eligible, Reason: Contributes backup next-—hop 
Backup Neighbor: 10.255.164.2 


Self to Neighbor Metric: 10, Backup preference: 


Backup Neighbor: 10.255.164.4 
Neighbor to Destination Metric: 20, Neighbor to 





Self to Neighbor Metric: 10, Backup preference: 
iiesele Weems 10.255, 164. i 


Neighbor to Destination Metric: 10, Neighbor to Self Metric: 


0x0 


Not evaluated, Reason: Interface is already covered 


Seillie Meicwsiles 


0x0 


Not evaluated, Reason: Interface is already covered 


U2 , WSS 2a 2 4 1g) 
Self to Destination Metric: 10 
Parent Node: 10.255.164.1 
Primary next—-hop: so-0/2/0.0 
Backup next-hop: t1-0/1/0.0 via 192.168.241.18 
Backup Neighbor: 10.255.164.3 (LSP endpoint) 
Neighbor to Destination Metric: 30, Neighbor to 
Self to Neighbor Metric: 20, Backup preference: 
Irecle Miecime 10.255. 164, i 
Weeiele Wess 10.255 164 2 
Nrat~ Koy aan Me — 111 ee 0 Pao 0 a oy 





Not eligible, Reason: Path loops 

Backup Neighbor: 10.255.164.4 

Neighbor to Destination Metric: 10, Neighbor to 
Self to Neighbor Metric: 10, Backup preference: 
Eligible, Reason: Contributes backup next-—hop 
Backup Neighbor: 10.255.164.2 





Neighbor to Destination Metric: 20, Neighbor to 
Self to Neighbor Metric: 10, Backup preference: 
each mesms 10,255, 164 i 


Seilie iMeiereske 9 


0x0 


Seilie iMeicresake 9 


0x0 


Sieilie Meee 


0x0 


Not evaluated, Reason: Interface is already covered 


IO. ASS 4164.2 
Self to Destination Metric: 10 
Parent Node: 192.168.241.2 
Parent Node: 192.168.242.2 
Dieiieiay MEEAneos SO-O/2/2.0 wae 192,163,242 6% 
Peaieuay inepe—Inloje icil—0)/il/A50 wWatel ILS ING Aa 
Backup Neighbor: 10.255.164.3 (LSP endpoint) 


Neighbor to Destination Metric: 10, Neighbor to Self Metric: 
0x0 


Self to Neighbor Metric: 20, Backup preference: 
each Mess 10,255,164 2 


Not evaluated, Reason: Primary next-hop multipath 


10 


10 


20 


10 


10 


20 
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Backup Neighbor: 10.255.164.2 
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 10 
Self to Neighbor Metric: 10, Backup preference: 0x0 
Not evaluated, Reason: Primary next-hop multipath 
Backup Neighbor: 10.255.164.4 
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 10 





Self to Neighbor Metric: 10, Backup preference: 0x0 
Gack sheem: Or 25 5) ue4 el 
Waaelke Weems 10). 2'55 164 2 





Not evaluated, Reason: Primary next-hop multipath 


10.255), 164.4 
Self to Destination Metric: 10 
Parent Node: 192.168.241.18 
Parent Node: 192.168.242.18 
Primary next—-hop: so-0/2/0.0 via 192.168.242.18 
Primary next—-hop: tl-0/1/0.0 vila 192.168.241.118 
Backup Neighbor: 10.255.164.3 (LSP endpoint) 
Neighbor to Destination Metric: 20, Neighbor to Self Metric: 20 
Self to Neighbor Metric: 20, Backup preference: 0x0 
Haalcleuelst=cmumel OR oreo den 
Not evaluated, Reason: Primary next-hop multipath 
Backup Neighbor: 10.255.164.4 
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 10 
Self to Neighbor Metric: 10, Backup preference: 0x0 
Not evaluated, Reason: Primary next-hop multipath 
Backup Neighbor: 10.255.164.2 
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SEE ALSO 


Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
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| Remote LFA over LDP Tunnels in OSPF Networks Overview 


In an OSPF network, a loop free alternate (LFA) is a directly connected neighbor that provides precomputed 
backup paths to the destinations reachable through the protected link on the point of local repair (PLR). 
A remote LFA is not directly connected to the PLR and provides precomputed backup paths using 
dynamically created LDP tunnels to the remote LFA node. The PLR uses this remote LFA backup path 
when the primary link fails. The primary goal of the remote LFA is to increase backup coverage for the 
OSPF networks and provide protection for Layer 1 metro-rings. 


LFAs do not provide full backup coverage for OSPF networks. This is a major setback for metro Ethernet 
networks that are often shaped as ring topologies. To overcome this setback, Resource Reservation Protocol 
- Traffic Engineering (RSVP-TE) backup tunnels are commonly used to extend the backup coverage. 
However, a majority of network providers have already implemented LDP as the MPLS tunnel setup 
protocol and do not want to implement the RSVP-TE protocol merely for backup coverage. LDP 
automatically brings up transport tunnels to all potential destinations in an OSPF network and hence is 
the preferred protocol. The existing LDP implemented for the MPLS tunnel setup can be reused for 
protection of OSPF networks and subsequent LDP destinations, thereby eliminating the need for RSVP-TE 
backup tunnels for backup coverage. 


To calculate the remote LFA backup path, the OSPF protocol determines the remote LFA node in the 
following manner: 


1. Calculates the reverse shortest path first from the adjacent router across the protected link of a PLR. 
The reverse shortest path first uses the incoming link metric instead of the outgoing link metric to reach 
a neighboring node. 


The result is a set of links and nodes, which is the shortest path from each leaf node to the root node. 


2. Calculates the shortest path first (SPF) on the remaining adjacent routers to find the list of nodes that 
can be reached without traversing the link being protected. 


The result is another set of links and nodes on the shortest path from the root node to all leaf nodes. 
3. Determines the common nodes from the above results. These nodes are the remote LFAs. 


OSPF listens to the advertised labels for the LDP routes. For each advertised LDP route, OSPF checks 
whether it contains an LDP supplied next hop. If the corresponding OSPF route does have a backup next 
hop, then OSPF runs the backup policy and adds an additional tracking route with the corresponding LDP 
label-switched path next hop as the backup next hop. If there are no backup next hops, LDP builds a 
dynamic LDP tunnel to the remote LFA, and LDP establishes a targeted adjacency between the remote 
LFA node and the PLR node. This backup route has two LDP labels. The top label is the OSPF route, which 
denotes the backup path from the PLR to the remote LFA route. The bottom label is the LDP MPLS 
label-switched path that denotes the route for reaching the ultimate destination from the remote LFA. 
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When an LDP session goes down and a remote tunnel is no longer available, OSPF changes all the routes 
that have been using this backup LDP tunnel. 


NOTE: Currently, Junos OS supports only IPv4 transport LSPs. If you need to reuse IPv4 transport 
LSPs for IPv6 IGP networks, add an IPv6 explicit NULL label to the label stack of the tracking 
route. The system automatically converts the IPv4 LSP to an IPvé LSP. 


LDP might be vulnerable by an automatically targeted adjacency, and these threats can be mitigated using 
all or some of the following mechanisms: 


e Remote LFAs that are several hops away use extended hello messages to indicate willingness to establish 
a targeted LDP session. A remote LFA can reduce the threat of spoofed extended hello messages by 
filtering them and accepting only those originating at sources permitted by an access or filter list. 


e There is a need to authenticate with TCP-MD5 all auto-targeted LDP sessions in the given IGP/LDP 
domain using apply groups or LDP global-level authentication. 


e As an added security measure, the repair or remote tunnel endpoint routers should be assigned from a 
set of addresses that are not reachable from outside of the routing domain. 


SEE ALSO 


auto-targeted-session 
no-eligible-remote-backup 


remote-backup-calculation | 734 


Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network 


The primary goal of a remote loop free alternate (LFA) is to increase backup coverage for OSPF routes 
and provide protection especially for Layer 1 metro-rings. The existing LDP implemented for the MPLS 
tunnel setup can be reused for protection of OSPF networks and subsequent LDP destinations. The OSPF 
protocol creates a dynamic LDP tunnel to reach the remote LFA node from the point of local repair (PLR). 
The PLR uses this remote LFA backup path when the primary link fails. 


Before you configure remote LFA over LDP tunnels in an OSPF network, you must do the following: 


1. Enable LDP on the loopback interface. 


Configure a loopback interface because an LDP targeted adjacency cannot be formed without a loopback 
interface. LDP targeted adjacency is essential for determining remote LFA backup paths. 
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2. Make sure that remote LFA allows asymmetric remote neighbor discovery—that is, it must send periodic 
targeted hello messages to the router that initiated the remote neighbor for LDP auto-targeted adjacency. 


3. Configure link protection or node-link protection on the PLR. 


To configure remote LFA backup over LDP tunnels in an OSPF network: 


1. Enable remote LFA backup to determine the backup next hop using dynamic LDP label-switched path. 


[edit protocols ospf backup-spf-options] 
user@host# set remote-backup-calculation 


2. Enable automatically targeted LDP sessions using the loopback addresses between the PLR and the 
remote LFA node. 


[edit protocols Idp] 
user@host# set auto-targeted-session 


3. Specify a time interval for which the targeted LDP sessions are kept up even after the remote LFA 
node goes down. 


[edit protocols Idp auto-targeted-session] 
user@host# set teardown-delay seconds 


For example, to set a teardown delay value of 60 seconds: 


[edit protocols Idp auto-targeted-session] 
user@host# set teardown-delay 60 


4. Specify the maximum number of automatically targeted LDP sessions to optimize memory usage. 


[edit protocols Idp auto-targeted-session] 
user@host# set maximum-sessions number of sessions 


For example, to set a maximum sessions allowed to 20: 


[edit protocols Idp auto-targeted-session] 
user@host# set maximum-sessions 20 
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SEE ALSO 


auto-targeted-session 
backup-spf-options | 618 
no-eligible-remote-backup 


remote-backup-calculation | 734 


| Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks 


IN THIS SECTION 


@ = Requirements | 371 
@ Overview | 372 

@® = Configuration | 372 
@ Verification | 382 


In an OSPF network, a loop free alternate(LFA) is a directly connected neighbor that provides precomputed 
backup paths to the destinations reachable via the protected link on the point of local repair (PLR). A 
remote LFA is not directly connected to the PLR and provides precomputed backup paths using dynamically 
created LDP tunnels to the remote LFA node. The PLR uses this remote LFA backup path when the primary 
link fails. The primary goal of the remote LFA is to increase backup coverage for the OSPF networks and 
provide protection for Layer 1 metro-rings. This example shows how to configure remote LFA for LDP 
tunnels in an OSPF network for extending backup protection. 


Requirements 


This example uses the following hardware and software components: 

e Nine MX Series routers with OSPF protocol and LDP enabled on the connected interfaces. 

e Junos OS Release 15.1 or later running on all devices. 

Before you configure remote LFA over LDP tunnels in an OSPF networks, make sure of the following: 


e LDPis enabled on the loopback interface. Without a loopback interface, LDP targeted adjacency cannot 
be formed. Remote LFA cannot be configured without LDP targeted adjacency. 


e Remote LFA must allow asymmetric remote neighbor discovery, that is, it must send periodic targeted 
hellos to the router that initiated the remote neighbor for LDP auto targeted adjacency. 
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e Link protection or node-link protection must be configured on the point of local repair (PLR). 


Overview 


The example includes nine routers in a ring topology. Configure the OSPF protocol on the directly connected 
interfaces. Device R6 is the PLR. This example verifies that Junos OS updates the routing table of Device 
R6 with LDP next-hop routes as the backup route. 


Topology 
In the topology Figure 23 on page 372 shows the remote LFA over LDP tunnels in OSPF networks is 


configured on Device R6. 


Figure 23: Example Remote LFA over LDP Tunnels 


ge-0/0/0 ge-0/0/1 
90.1.1.2/24 100.1.1.2/24 


R8 
ge-0/0/1 ge-0/0/3 
90.1.1.1/24 1O0.1.1.1/24)"  ge-0/0/2 ge-0/0/2 ge-0/0/1 ge-0/0/0 
an ge-0/0/0 ge-0/0/0 80.11.1/24 80.11.2/24 70.1.1.1/24 70.1.1.2/24 
10.1.1.1/24 10.1.1.2/24 
ge-0/0/2 ge-0/0/1 ml R6 “| ge-0/0/0 R7 
T10.1.1.1/24 20.11.1/24 60.1.1.2/24 
ge-0/0/1 
ge-0/0/2 ge-0/0/0 60.1.1.1/24 
110.1.1.2/24 20.1.1.2/24 
R5 
ge-ovos1| R2 ge-0/0/0 
30.11.1/24 50.1.1.2/24 
ge-0/0/0 ge-0/0/1 
30.1.1.2/24 50.1.1.1/24 
ge-0/0/1 ge-0/0/0 
Rg 404.1.1/24 40.1.1.2/24 py 
loO: 
RO 1.1.1.1/32 R5 6.6.6.6/32 
RI 2.2.2.2/32 R6 = 7.7.7.7/32 
R2  3.3.3.3/32 R7 8.8.8.8/32 
R3 4.4.4.4/32 R8 9.9.9.9/32 


R4 5,5.5,5/32 


g043140 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


RO 


R1 


set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 90.1.1.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 110.1.1.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.1/32 

set interfaces loO unit O family mpls 

set routing-options static route 88.88.88.88/32 discard 

set routing-options router-id 1.1.1.1 

set routing-options forwarding-table export per-packet 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface lo0.0 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf export static 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 
set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp egress-policy static 

set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface ge-0/0/2.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 
set policy-options policy-statement static from protocol static 
set policy-options policy-statement static then accept 


set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 
set interfaces ge-0/0/1 unit 0 family inet address 20.1.1.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 80.1.1.1/24 


373 


R2 


R3 


set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 100.1.1.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 2.2.2.2/32 

set interfaces loO unit O family mpls 

set routing-options router-id 2.2.2.2 

set routing-options forwarding-table export per-packet 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 link-protection 
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface ge-0/0/2.0 

set protocols Idp interface ge-0/0/3.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


set interfaces ge-0/0/0 unit 0 family inet address 20.1.1.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 30.1.1.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 110.1.1.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 3.3.3.3/32 

set interfaces loO unit O family mpls 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 
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set interfaces ge-0/0/0 unit 0 family inet address 30.1.1.2/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 40.1.1.1/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 4.4.4.4/32 

set interfaces loO unit O family mpls 

set routing-options router-id 4.4.4.4 

set routing-options forwarding-table export per-packet 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


set interfaces ge-0/0/0 unit 0 family inet address 40.1.1.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 50.1.1.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 5.5.5.5/32 

set interfaces loO unit O family mpls 

set routing-options router-id 5.5.5.5 

set routing-options forwarding-table export per-packet 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 60 
set protocols Idp auto-targeted-session maximum-sessions 20 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 
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set protocols Idp interface lo0.0 
set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


set interfaces ge-0/0/0 unit 0 family inet address 50.1.1.2/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 60.1.1.1/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 6.6.6.6/32 

set interfaces loO unit O family mpls 

set routing-options router-id 6.6.6.6 

set routing-options forwarding-table export per-packet 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


set interfaces ge-0/0/0 unit 0 family inet address 60.1.1.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 70.1.1.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 80.1.1.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 7.7.7.7/32 

set interfaces loO unit O family mpls 
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set routing-options router-id 7.7.7.7 

set routing-options forwarding-table export per-packet 

set protocols ospf topology default backup-spf-options remote-backup-calculation 
set protocols ospf backup-spf-options remote-backup-calculation 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 link-protection 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 link-protection 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 link-protection 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 

set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface ge-0/0/2.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


set interfaces ge-0/0/0 unit 0 family inet address 70.1.1.2/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 8.8.8.8/32 

set interfaces loO unit O family mpls 

set routing-options router-id 8.8.8.8 

set routing-options forwarding-table export per-packet 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface lo0.0 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


377 


set interfaces ge-0/0/0 unit 0 family inet address 90.1.1.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 100.1.1.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 9.9.9.9/32 

set interfaces loO unit O family mpls 

set routing-options router-id 9.9.9.9 

set routing-options forwarding-table export per-packet 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface lo0.0 

set protocols ospf backup-spf-options remote-backup-calculation 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols Idp auto-targeted-session teardown-delay 20 

set protocols Idp auto-targeted-session maximum-sessions 60 
set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement per-packet then load-balance per-packet 
set policy-options policy-statement per-packet then accept 


Configuring Device R6 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R6é: 


1. Configure the interfaces. 


[edit interfaces] 
user@R6# set ge-0/0/0 unit O family inet address 60.1.1.2/24 
user@R6# set ge-0/0/0 unit 0 family mpls 


user@R6# set ge-0/0/1 unit O family inet address 70.1.1.1/24 
user@R6# set ge-0/0/1 unit 0 family mpls 


user@R6# set ge-0/0/2 unit 0 family inet address 80.1.1.2/24 
user@R6# set ge-0/0/2 unit 0 family mpls 
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. Assign the loopback addresses to the device. 


[edit loO unit O family] 
user@R6# set address 7.7.7.7/32 
user@R6# set mpls 


. Configure the router ID. Apply the policy to the forwarding table of the local router with the export 
statement. 


[edit routing-options] 
user@R6# set router-id 7.7.7.7 
user@R6# set forwarding-table export per-packet 


. Enable remote LFA backup which calculates the backup next hop using dynamic LDP label-switched 
path. 


[edit protocols ospf] 
user@R6# set topology default backup-spf-options remote-backup-calculation 
user@R6# set backup-spf-options remote-backup-calculation 


. Configure the traffic engineering and the link protection for the interfaces in the OSPF area. 


[edit protocols ospf] 

user@R6# set traffic-engineering 

user@R6# set area 0.0.0.0 interface ge-0/0/0.0 link-protection 
user@R6# set area 0.0.0.0 interface ge-0/0/1.0 link-protection 
user@R6# set area 0.0.0.0 interface ge-0/0/2.0 link-protection 
user@R6# set area 0.0.0.0 interface lo0.0 


. Specify a time interval for which the targeted LDP sessions are kept up when the remote LFA goes 
down, and specify a maximum number of automatically, targeted LDP sessions to optimize the use of 
memory. 


[edit protocols Idp] 
user@R6# set auto-targeted-session teardown-delay 20 
user@R6# set auto-targeted-session maximum-sessions 60 


. Configure the LDP protocols on the interfaces. 
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[edit protocols Idp] 

user@R6# set interface ge-0/0/0.0 
user@R6# set interface ge-0/0/1.0 
user@R6# set interface ge-0/0/2.0 
user@R6¢# set interface lo0.0 


8. Configure the policy options to load balance the per-packet of the policy-statement routing policy. 


[edit policy-options policy-statement] 
user@R6# set per-packet then load-balance per-packet 
user@R6# set per-packet then accept 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R6# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 60.1.1.2/24; 
} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 70.1.1.1/24; 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 80.1.1.2/24; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 7.7.7.7/32; 
} 


family mpls; 


user@R6# show protocols 
ospf { 
topology default { 
backup-spf-options { 
remote-backup-calculation; 


} 
backup-spf-options { 
remote-backup-calculation; 
inactive: per-prefix-calculation all; 
} 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/0.0 { 
link-protection; 
} 
interface ge-0/0/1.0 { 
link-protection; 
} 
interface ge-0/0/2.0 { 
link-protection; 
} 


interface 100.0; 


} 
Idp { 
auto-targeted-session { 
teardown-delay 20; 
maximum-sessions 60; 
} 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface 100.0; 
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user@R6# show policy-options 
policy-statement per-packet { 
then { 
load-balance per-packet; 


accept; 


user@R6# show routing-options 
router-id 7.7.7.7; 
forwarding-table { 

export per-packet; 


If you are done configuring the device, enter commit from the configuration mode. 


Verification 


IN THIS SECTION 


Verifying the Routes | 382 
Verifying the LDP Routes | 385 


e 

e 

@ Verifying the OSPF Routes | 385 

@ Verifying the Designated Backup Path Node | 387 
t 


Verifying the Backup Neighbors | 388 


Confirm that the configuration is working properly. 


Verifying the Routes 


Purpose 


Verify that the expected routes are learned. 


Action 


383 
On Device R6, from operational mode, run the show route 6.6.6.6/24 command to display the routes in 
the routing table. 


user@R6> show route 6.6.6.6/24 


suai 08 YS clasiciineicieas, 75 mouces (7S aciciwa, O lnoilelelom, ©) Imarelkelein)) 








+ = Active Route, Last Active, * = Both 
55666. 6/ 32 “OS2r/ 10 ]| O2e21c07, merciene ab 
> co SO ,l,1.l wie Ge-0/0/0.0 


tO SO,1,1,1 yiea ge-0/0/2.0, Pusla 299872 


inet.3: 7 destinations, 7 routes (7 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


536.6. 6/32 “De /S)]) O2s2QisO07, mercieie 
Sto 60,11, wa ge-0/0/0.0 
co BO,1,1,1 wia oe-O/0/2.0, Pusia 299N7I2, wwii 272 (icejs)) 


inet.0: 75 destinations, 75 routes (75 active, 0 holddown, O hidden) 
6.6.6.6/32 (1 entry, 1 announced) 

State: <FlashAll> 

AO Si Preference: 10 
Next hop type: Router, Next hop index: 1048585 
Address: 0x9df2690 





Next-hop reference count: 10 

Next hop: 60.1.1.1 via ge-0/0/0.0 weight 0x1, selected 
Session Id: 0x141 

Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote 





neighbor path 
Label operation: Push 299872 

Label TTL action: prop-ttl 

Load balance label: Label 299872: None; 
Label element ptr: 0x9dc27a0 


Label parent element ptr: 0x0 





Label element references: 6 





Label element child references: 4 














Label element lsp id: 0 
Session Id: 0x142 
State: <Active Int> 


Age: 2:22:40 Metric: 1 


cineieeS cya ecesiean 


6.6.6.6/32 (1 en 
State: <FlashAll 
* LDP 


neighbor path 


Meaning 
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Validation State: unverified 

Mees Oo0.0.0 

Task (SPE 

Announcement bits (2): O-KRT 4-LDP 
AMS jOenclag I 


ations, 7 routes (7 active, 0 holddown, 0 hidden) 


try, 1 announced) 
> 
Preference: 9 

Next hop type: Router, Next hop index: 0 
Address: 0x9df2a90 





Next-hop reference count: 1 

Next hop: 60.1.1.1 via ge-0/0/0.0 weight 0x1, selected 
Label element ptr: 0x9dc0dc0 

Label parent element ptr: 0x0 





Label element references: 1 





Label element child references: 0 

Label element lsp id: 0 

Session Id: 0x0 

Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote 


Label operation: Push 299792, Push 299872 (top) 

alge Will) AGEMOME joe e-icicll, jsieCo-iticll (ito) 

Load balance label: Label 299792: None; Label 299872: None; 
Label element ptr: 0x9dclba0 

Label parent element ptr: 0x9dc27a0 


Label element references: 1 





Label element child references: 0 














Label element lsp id: 0 

Session Id: 0x0 

State: <Active Int> 

Age: 2:22:40 Metric: 1 

Validation State: unverified 

Tek ILD 

Announcement bits (1): O-Resolve tree 1 


AS@pathiel 


The output shows all the routes in the routing table of Device R6. 


Verifying the LDP Routes 


Purpose 


Verify the automatically targeted LDP routes. 


Action 


From operational mode, enter the show Idp session auto-targeted detail command. 


user@R6>show Idp session auto-targeted detail 


Address: 4.4.4.4, State: Operational, Connection: Open, Hold time: 


SSsSioOi WS Vota lo 120—-—4.4,4., 480 

Next keepalive in 8 seconds 

Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 
Neighbor types: auto-targeted 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 7.7.7.7, Remote address: 4.4.4.4 

UO ioe O29239 28) 





Capabilities advertised: non 





Capabilities received: non 





Protection: disabled 


Session flags: none 





Local - Restart: disabled, Helper mode: enabled 





Remote — Restart: disabled, Helper mode: enabled 
Local maximum neighbor reconnect time: 120000 msec 


Local maximum neighbor recovery time: 240000 msec 





Local Label Advertisement mode: Downstream unsolicited 





Remote Label Advertisement mode: Downstream unsolicited 





Negotiated Label Advertisement mode: Downstream unsolicited 
MTU discovery: disabled 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
4.4.4.4 

3051,162 

A A dl gil 

128, 92525537) 


Verifying the OSPF Routes 


Purpose 


Display all the LDP backup routes in the OSPF routing table of Device R6. 
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Action 


On Device R6, from operational mode, run the show ospf route command to display the routes in the 


OSPF routing table. 


user@R6> show ospf route 


Topology default Route Table: 
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Meaning 
The output shows all the LDP backup routes in the OSPF routing table of Device Ré. 


Verifying the Designated Backup Path Node 


Purpose 
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Action 


From operational mode, enter the show ospf backup spf results command. 


user@R6> show ospf backup spf results 


Topology default results: 


Area 0.0.0.0 results: 


956566.6 

Self to Destination Metric: 1 

Parent Node: 60.1.1.2 

Primary next-hop: ge-0/0/0.0 via 60.1.1.1 

Backup next-hop: LDP->4.4.4.4 via ge-0/0/2.0 

Backup Neighbor: 6.6.6.6 via: Direct 
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1, Backup preference: 0x0 
Not eligible, Reason: Primary next-hop link fate sharing 
Backup Neighbor: 2.2.2.2 via: Direct 
Neighbor to Destination Metric: 2, Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1, Backup preference: 0x0 
Not eligible, Reason: Path loops 
Backup Neighbor: 8.8.8.8 via: Direct 
Neighbor to Destination Metric: 2, Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1, Backup preference: 0x0 
Not eligible, Reason: Path loops 
Backup Neighbor: 4.4.4.4 via: LDP (LSP endpoint) 





Neighbor to Destination Metric: 2, Neighbor to Self Metric: 3 





Self to Neighbor Metric: 3, Backup preference: 0x0 





Eligible, Reason: Contributes backup next-—hop 


Meaning 


The output indicates whether a specific interface or node has been designated as a remote backup path 
and why. 


Verifying the Backup Neighbors 


Purpose 


Display the backup neighbors for the Device R6 
Action 


From operational mode, enter the show ospf backup neighbor command. 
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user@R6>show ospf backup neighbor 


Topology default backup neighbors: 
Area 0.0.0.0 backup neighbors: 


6.6.6.6 via: Direct 
Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1 
Direct next-hop: ge-0/0/0.0 via 60.1.1.1 


S.868.8 Whlag Dilwecir 
Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1 
Direct next-hop: ge-0/0/1.0 via 70.1.1.2 


Do ohod GLA WalTeSCie 
Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1 





Dileecle merece: es-0/0/2.,0 wie SO 1, toi 


4.4.4.4 via: LDP (LSP endpoint) 
Neighbor to Self Metric: 3 
Self to Neighbor Metric: 3 
|Daiag={o) ON OL: otal Lo) oan D) => 7/ ana Woer/ Mawr Mla Vault -Wo (= OV 07 YAO) 








DACA MeEXe—neoes De—S4.,4 4,4 wie ge-0/0/0.0 
Neighbors Protected: 2 


Meaning 


The output displays the backup neighbors available for area 0.0.0.0. 


SEE ALSO 


auto-targeted-session 
no-eligible-remote-backup 


remote-backup-calculation | 734 


RELATED DOCUMENTATION 
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Configuring OSPF Support for Traffic Engineering 


IN THIS SECTION 


OSPF Support for Traffic Engineering | 392 

Example: Enabling OSPF Traffic Engineering Support | 394 

Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 401 
OSPF Passive Traffic Engineering Mode | 403 

Example: Configuring OSPF Passive Traffic Engineering Mode | 403 

Advertising Label-Switched Paths into OSPFv2 | 406 

Example: Advertising Label-Switched Paths into OSPFv2 | 407 

Static Adjacency Segment Identifier for OSPF | 423 


Understanding Source Packet Routing in Networking (SPRING) | 427 


| OSPF Support for Traffic Engineering 


Traffic engineering allows you to control the path that data packets follow, bypassing the standard routing 
model, which uses routing tables. Traffic engineering moves flows from congested links to alternate links 
that would not be selected by the automatically computed destination-based shortest path. 


To help provide traffic engineering and MPLS with information about network topology and loading, 
extensions have been added to the Junos OS implementation of OSPF. When traffic engineering is enabled 
on the routing device, you can enable OSPF traffic engineering support. When you enable traffic engineering 
for OSPF, the shortest-path-first (SPF) algorithm takes into account the various label-switched paths (LSPs) 
configured under MPLS and configures OSPF to generate opaque link-state advertisements (LSAs) that 
carry traffic engineering parameters. The parameters are used to populate the traffic engineering database. 
The traffic engineering database is used exclusively for calculating explicit paths for the placement of LSPs 
across the physical topology. The Constrained Shortest Path First (CSPF) algorithm uses the traffic 
engineering database to compute the paths that MPLS LSPs take. RSVP uses this path information to set 
up LSPs and to reserve bandwidth for them. 


By default, traffic engineering support is disabled. To enable traffic engineering, include the 


traffic-engineering statement. You can also configure the following OSPF traffic engineering extensions: 


advertise-unnumbered-interfaces—(OSPFv2 only) Advertises the link-local identifier in the link-local 
traffic engineering LSA packet. You do not need to include this statement if RSVP is able to signal 
unnumbered interfaces as defined in RFC 3477, Signalling Unnumbered Links in Resource Reservation 
Protocol - Traffic Engineering (RSVP-TE). 


credibility-protocol-preference—(OSPFv2 only) Assigns a credibility value to OSPF routes in the traffic 
engineering database. By default, Junos OS prefers IS-IS routes in the traffic engineering database over 
other interior gateway protocol (IGP) routes even if the routes of another IGP are configured with a 
lower, that is, more preferred, preference value. The traffic engineering database assigns a credibility 
value to each IGP and prefers the routes of the IGP with the highest credibility value. In Junos OS Release 
9.4 and later, you can configure OSPF to take protocol preference into account to determine the traffic 
engineering database credibility value. When protocol preference is used to determine the credibility 
value, IS-IS routes are not automatically preferred by the traffic engineering database, depending on 
your configuration. 


ignore-lsp-metrics—lgnores RSVP LSP metrics in OSPF traffic engineering shortcut calculations or when 
you configure LDP over RSVP LSPs. This option avoids mutual dependency between OSPF and RSVP, 
eliminating the time period when the RSVP metric used for tunneling traffic is not up to date. In addition, 
If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution 
of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established 
by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops. 


multicast-rpf-routes—(OSPFv2 only) Installs unicast IPv4 routes (not LSPs) in the multicast routing table 
(inet.2) for multicast reverse-path forwarding (RPF) checks. The inet.2 routing table consists of unicast 
routes used for multicast RPF lookup. RPF is an antispoofing mechanism used to check if the packet is 
coming in on an interface that is also sending data back to the packet source. 


no-topology—(OSPF v2 only) To disable the dissemination of link-state topology information. If disabled, 
traffic engineering topology information is no longer distributed within the OSPF area. 


shortcuts—Configures IGP shortcuts, which allows OSPF to use an LSP as the next hop as if it were a 
logical interface from the ingress routing device to the egress routing device. The address specified in 
the to statement at the [edit protocols mpls label-switched-path Isp-path-name] hierarchy level on the 
ingress routing device must match the router ID of the egress routing device for the LSP to function as 
a direct link to the egress routing device and to be used as input to the OSPF SPF calculations. When 
used in this way, LSPs are no different from Asynchronous Transfer Mode (ATM) and Frame Relay virtual 
circuits (VCs), except that LSPS carry only IPv4 traffic. 


OSPF v2 installs the prefix for IPv4 routes in the inet.0 routing table, and the LSPs are installed by default 
in the inet.3 routing table. 


OSPFv3 LSPs used for shortcuts continue to be signaled using IPv4. However, by default, shortcut IPv6é 
routes calculated through OSPFv3 are added to the inet6.3 routing table. The default behavior is for 
BGP only to use LSPs in its calculations. If you configure MPLS so that both BGP and IGPs use LSPs for 
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forwarding traffic, IPv6é shortcut routes calculated through OSPFv3 are added to the inet6.0 routing 
table. 


NOTE: Whenever possible, use OSPF IGP shortcuts instead of traffic engineering shortcuts. 


e Isp-metric-info-summary—Advertises the LSP metric in summary LSAs to treat the LSP as a link. This 
configuration allows other routing devices in the network to use this LSP. To accomplish this, you need 
to configure MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs. 


When you enable traffic engineering on the routing device, you can also configure an OSPF metric that is 
used exclusively for traffic engineering. The traffic engineering metric is used for information injected into 
the traffic engineering database. Its value does not affect normal OSPF forwarding. 


Example: Enabling OSPF Traffic Engineering Support 


IN THIS SECTION 


Requirements | 394 
Overview | 395 
Configuration | 395 


Verification | 400 


This example shows how to enable OSPF traffic engineering support to advertise the label-switched path 
(LSP) metric in summary link-state advertisements (LSAs). 


Requirements 


Before you begin: 
e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 
e Configure BGP per your network requirements. See the BGP User Guide 


e Configure MPLS per your network requirements. See the MPLS Applications User Guide. 


395 


Overview 


You can configure OSPF to treat an LSP as a link and have other routing devices in the network use this 
LSP. To accomplish this, you configure MPLS and OSPF traffic engineering to advertise the LSP metric in 
summary LSAs. 


In this example, there are four routing devices in area 0.0.0.0, and you want OSPF to treat the LSP named 
R1-to-R4 that goes from the ingress Device R1 to the egress Device R4 as a link. 


For OSPF, you enable traffic engineering on all four routing devices in the area by including the 
traffic-engineering statement. This configuration ensures that the shortest-path-first (SPF) algorithm takes 
into account the LSPs configured under MPLS and configures OSPF to generate LSAs that carry traffic 
engineering parameters. You further ensure that OSPF uses the MPLS LSP as the next hop and advertises 
the LSP metric in summary LSAs, by including the optional shortcuts Isp-metric-into-summary statement 
on the ingress Device R1. 


For MPLS, you enable traffic engineering so that MPLS performs traffic engineering on both BGP and IGP 
destinations by including the traffic-engineering bgp-igp statement, and you include the LSP named 
R1-to-R4 by including the label-switched-path Isp-path-name to address statement on the ingress Device 
R1. The address specified in the to statement on the ingress Device R1 must match the router ID of the 
egress Device R4 for the LSP to function as a direct link to the egress routing device and to be used as 
input to the OSPF SPF calculations. In this example, the router ID of the egress Device R4 is 10.0.0.4. 


Configuration 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide. 


CLI Quick Configuration 


To quickly enable OSPF traffic engineering support to advertise the LSP metric in summary LSAs, copy 
the following commands and paste them into the CLI. 


Configuration on R1: 


[edit] 

set routing-options router-id 10.0.0.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf traffic-engineering shortcuts Isp-metric-into-summary 
set protocols mpls traffic-engineering bgp-igp 

set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4 


Configuration on R2: 


[edit] 

set routing-options router-id 10.0.0.2 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
set protocols ospf traffic-engineering 


Configuration on R3: 


[edit] 

set routing-options router-id 10.0.0.3 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
set protocols ospf traffic-engineering 


Configuration on R4: 


[edit] 

set routing-options router-id 10.0.0.4 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
set protocols ospf traffic-engineering 


Step-by-Step Procedure 


To enable OSPF traffic engineering support to advertise LSP metrics in summary LSAs: 


1. Configure the router ID. 


[edit] 
user@R1# set routing-options router-id 10.0.0.1 


[edit] 
user@R2# set routing-options router-id 10.0.0.2 


[edit] 
user@R3# set routing-options router-id 10.0.0.3 


[edit] 
user@R4# set routing-options router-id 10.0.0.4 


2. Configure the OSPF area and add the interfaces. 
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NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@R1# set protocols ospf area 0.0.0.0 interface all 
user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


[edit] 
user@R2# set protocols ospf area 0.0.0.0 interface all 
user@R2# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


[edit] 
user@R3# set protocols ospf area 0.0.0.0 interface all 
user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


[edit] 
user@R4# set protocols ospf area 0.0.0.0 interface all 
user@R4# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


3. Enable OSPF traffic engineering. 


[edit] 
user@R1# set protocols ospf traffic-engineering shortcuts |sp-metric-into-summary 


[edit] 
user@R2# set protocols ospf traffic-engineering 


[edit] 
user@R3# set protocols ospf traffic-engineering 


[edit] 
user@R4# set protocols ospf traffic-engineering 


4. On Device R1, configure MPLS traffic engineering. 
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[edit ] 
user@R1# set protocols mpls traffic-engineering bgp-igp 
user@R1# set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4 


5. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show routing-options, show protocols ospf, and show protocols 
mpls commands. If the output does not display the intended configuration, repeat the instructions in this 
example to correct the configuration. 


Output for R11: 


user@host# show routing-options 
router-id 10.0.0.1; 


user@host# show protocols ospf 

traffic-engineering { 

shortcuts Isp-metric-into-summary; 
} 
area 0.0.0.0 { 

interface all; 

interface fxp0.0 { 

disable; 


user@host# show protocols mpls 
traffic-engineering bgp-igp; 
label-switched-path R1-to-R4 { 
to 10.0.0.4; 


Output for R2: 


user@host# show routing-options 
router-id 10.0.0.2; 
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user@host# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


Output for R3: 


user@host# show routing-options 
router-id 10.0.0.3; 


user@host# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


Output for R4: 


user@host# show routing-options 
router-id 10.0.0.4; 


user@host# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


To confirm your OSPFv3 configuration, enter the show routing-options, show protocols ospf3, and show 
protocols mpls commands. 
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Verification 


IN THIS SECTION 


@ = Verifying the Traffic Engineering Capability for OSPF | 400 
@ Verifying OSPF Entries in the Traffic Engineering Database | 400 


@ Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF | 400 


Confirm that the configuration is working properly. 
Verifying the Traffic Engineering Capability for OSPF 
Purpose 


Verify that traffic engineering has been enabled for OSPF. By default, traffic engineering is disabled. 


Action 
From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 
overview for OSPF v3. 


Verifying OSPF Entries in the Traffic Engineering Database 


Purpose 
Verify the OSPF information in the traffic engineering database. The Protocol field displays OSPF and the 
area from which the information was learned. 


Action 

From operational mode, enter the show ted database command. 

Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF 
Purpose 


Verify that OSPF is reporting node information. The Protocol name field displays OSPF and the area from 
which the information was learned. 


Action 


From operational mode, enter the show ted protocol command. 
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Example: Configuring the Traffic Engineering Metric for a Specific OSPF 
Interface 


IN THIS SECTION 


Requirements | 401 
Overview | 401 
Configuration | 401 


Verification | 403 


This example shows how to configure the OSPF metric value used for traffic engineering. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


e Configure OSPF for traffic engineering. See “Example: Enabling OSPF Traffic Engineering Support” on 
page 394 


Overview 


You can configure an OSPF metric that is used exclusively for traffic engineering. To modify the default 
value of the traffic engineering metric, include the te-metric statement. The OSPF traffic engineering 
metric does not affect normal OSPF forwarding. By default, the traffic engineering metric is the same value 
as the OSPF metric. The range is 1 through 65,535. 


In this example, you configure the OSPF traffic engineering metric on OSPF interface fe-0/1/1 in area 
0.0.0.0. 


Configuration 


CLI Quick Configuration 

To quickly configure the OSPF traffic engineering metric for a specific interface, copy the following 
commands, paste them into a text file, remove any line breaks, change any details necessary to match your 
network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then 
enter commit from configuration mode. 
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[edit] 
set protocols ospf area 0.0.0.0 interface fe-0/1/1 te-metric 10 


Step-by-Step Procedure 


To configure an OSPF traffic engineering metric for a specific interface used only for traffic engineering: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf area 0.0.0.0 


2. Configure the traffic engineering metric of the OSPF network segments. 


[edit protocols ospf area 0.0.0.0] 
user@host set interface fe-0/1/1 te-metric 10 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf area 0.0.0.0] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/1/1.0 { 
te-metric 10; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 
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Verification 


Confirm that the configuration is working properly. 
Verifying the Configured Traffic Engineering Metric 


Purpose 


Verify the traffic engineering metric value. Confirm that Metric field displays the configured traffic 
engineering metric. 


Action 


From operational mode, enter the show ted database extensive command. 


| OSPF Passive Traffic Engineering Mode 


Ordinarily, interior routing protocols such as OSPF are not run on links between autonomous systems. 
However, for inter-AS traffic engineering to function properly, information about the inter-AS link—in 
particular, the address on the remote interface—must be made available inside the autonomous system 
(AS). This information is not normally included either in the external BGP (EBGP) reachability messages or 
in the OSPF routing advertisements. 


To flood this link address information within the AS and make it available for traffic engineering calculations, 
you must configure OSPF passive mode for traffic engineering on each inter-AS interface. You must also 
supply the remote address for OSPF to distribute and include it in the traffic engineering database. OSPF 
traffic engineering mode allows MPLS label-switched paths (LSPs) to dynamically discover OSPF AS 
boundary routers and to allow routers to establish a traffic engineering LSP across multiple autonomous 
systems. 


| Example: Configuring OSPF Passive Traffic Engineering Mode 


IN THIS SECTION 


Requirements | 404 
Overview | 404 
Configuration | 404 


Verification | 406 
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This example shows how to configure OSPF passive mode for traffic engineering on an inter-AS interface. 
The AS boundary router link between the EBGP peers must be a directly connected link and must be 
configured as a passive traffic engineering link. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


Configure BGP per your network requirements. See the BGP User Guide. 


Configure the LSP per your network requirements. See the MPLS Applications User Guide. 


Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


You can configure OSPF passive mode for traffic engineering on an inter-AS interface. The address used 
for the remote node of the OSPF passive traffic engineering link must be the same as the address used 
for the EBGP link. In this example, you configure interface so-1/1/0 in area 0.0.0.1 as the inter-AS link to 
distribute traffic engineering information with OSPF within the AS and include the following settings: 


e passive—Advertises the direct interface addresses on an interface without actually running OSPF on 
that interface. A passive interface is one for which the address information is advertised as an internal 
route in OSPF, but on which the protocol does not run. 


e traffic-engineering—Configures an interface in OSPF passive traffic-engineering mode to enable dynamic 
discovery of OSPF AS boundary routers. By default, OSPF passive traffic-engineering mode is disabled. 


e remote-node-id—Specifies the IP address at the far end of the inter-AS link. In this example, the remote 
IP address is 192.168.207.2. 


Configuration 


To quickly configure OSPF passive mode for traffic engineering, copy the following command, remove 
any line breaks, and paste it into the CLI. 
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[edit] 
set protocols ospf area 0.0.0.1 interface so-1/1/0 passive traffic-engineering remote-node-id 192.168.207.2 


Step-by-Step Procedure 


To configure OSPF passive traffic engineering mode: 


1. Create an OSPF area. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# set protocols ospf area 0.0.0.1 


2. Configure interface so-1/1/0 as a passive interface configured for traffic engineering, and specify the 
IP address at the far end of the inter-AS link. 


[edit protocols ospf area 0.0.0.1] 
user@host# set interface so-1/1/0 passive traffic-engineering remote-node-id 192.168.207.2 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
area 0.0.0.1 { 
interface so-1/1/0.0 { 
passive { 
traffic-engineering { 
remote-node-id 192.168.207.2; 
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To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Status of OSPF Interfaces 


Purpose 


Verify the status of OSPF interfaces. If the interface is passive, the Adj count field is O because no 
adjacencies have been formed. Next to this field, you might also see the word Passive. 


Action 


From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show 
ospf3 interface detail command for OSPFv3. 


Advertising Label-Switched Paths into OSPFv2 


One main reason to configure label-switched paths (LSPs) in your network is to control the shortest path 
between two points on the network. You can advertise LSPs into OSPFv2 as point-to-point links so that 
all participating routing devices can take the LSP into account when performing SPF calculations. The 
advertisement contains a local address (the from address of the LSP), a remote address (the to address of 
the LSP), and a metric with the following precedence: 


1. Use the LSP metric defined under OSPFv2. 


2. Use the LSP metric configured for the label-switched path under MPLS. 


3. If you do not configure any of the above, use the default OSPFv2 metric of 1. 


NOTE: If you want an LSP that is announced into OSPF v2 to be used in SPF calculations, there 
must be a reverse link (that is, a link from the tail end of the LSP to the head end). You can 
accomplish this by configuring an LSP in the reverse direction and also announcing it in OSPFv2. 
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| Example: Advertising Label-Switched Paths into OSPFv2 


IN THIS SECTION 


Requirements | 407 
Overview | 407 
Configuration | 409 


Verification | 423 


This example shows how to advertise LSPs into OSPFv2. 


Requirements 


Before you begin, configure the device interfaces. See the Junos OS Network Interfaces Library for Routing 


Devices. 


Overview 


To advertise an LSP into OSPFv2, you define the LSP and configure OSPF v2 to route traffic using the LSP. 
By doing this, you can use the LSP to control the shortest path between two points on the network. You 
might choose to do this if you want to have OSPF traffic routed along the LSP instead of having OSPF use 
the default best-effort routing. 


In this example, you configure the following to advertise an LSP into OSPFv2: 


e BGP 


For all routing devices, configure the local AS number 65000 and define the IBGP group that recognizes 
the specified BGP systems as peers. All members are internal to the local AS, so you configure an internal 
group with a full list of peers. You also include the peer AS group, which is the same as the local AS 
number that you configure. 


e MPLS 


For all routing devices, configure the protocol family on each transit logical interface and enable MPLS 
on all interfaces, except for the management interface (fxp0.0). Specify the mpls protocol family type. 


e RSVP 


For all routing devices, enable RSVP onall interfaces, except for the management interface (fxp0.0). You 
enable RSVP on the devices in this network to ensure that the interfaces can signal the LSP. 
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OSPFv2 


For all routing devices, use the loopback address to assign the router ID, administratively group all of 
the devices into OSPF area 0.0.0.0, add all of the interfaces participating in OSPF to area 0.0.0.0, and 
disable OSPF on the management interface (fxp0.0). 


Label-switched path 


On the ingress routing device R1, which is the beginning (or head end) of the LSP, configure an LSP with 
an explicit path. The explicit path indicates that the LSP must go to the next specified IP address in the 
path without traversing other nodes. In this example, you create an LSP named R1-to-R6, and you specify 
the IP address of the egress routing device R6. 


Advertise the LSP in OSPFv2 


On the ingress routing device R1, you advertise the LSP as a point-to-point link into OSPFv2. You can 
optionally assign a metric to have the LSP be the more or less preferred path to the destination. 


Figure 24 on page 409 shows a sample network topology that consists of the following: 


BGP is configured on all routing devices, with one local autonomous system (AS) 65000 that contains 
three routing devices: 


e R1i—Device R1 is the ingress device with a router ID of 10.0.0.1. Interface so-0/0/2 connects to Device 
R3. 


e R3—Device R3 is the transit device with a router ID of 10.0.0.3. Interface so-0/0/2 connects to Device 
R1, and interface so-0/0/3 connects to Device R6. 


e R6—Device R6 is the egress device with a router ID of 10.0.0.6. Interface so-0/0/3 connects to Device 
R3. 


OSPF v2 is configured on all routing devices. 
MPLS and RSVP are enabled on all routing devices. 
One RSVP-signaled LSP is configured on Device R1. 


Figure 24: Advertising an LSP into OSPFv2 
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Configuration 


IN THIS SECTION 


Configuring BGP | 409 

Configuring MPLS | 412 

Configuring RSVP | 416 

Configuring OSPF | 418 

Configuring the LSP | 420 

Advertising the LSP into OSPFv2 | 421 


The following examples require you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide. 


To configure the devices to advertise an LSP into OSPFv2, perform the following tasks: 


Configuring BGP 


CLI Quick Configuration 


To quickly configure BGP on each routing device, copy the following commands and paste them into the 


CLI. 


Configuration on Device R1: 


[edit] 
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set routing-options autonomous-system 65000 

set protocols bgp group internal-peers type internal 

set protocols bgp group internal-peers local-address 10.0.0.1 
set protocols bgp group internal-peers neighbor 10.0.0.3 

set protocols bgp group internal-peers neighbor 10.0.0.6 

set protocols bgp group internal-peers peer-as 65000 


Configuration on Device R3: 


[edit] 

set routing-options autonomous-system 65000 

set protocols bgp group internal-peers type internal 

set protocols bgp group internal-peers local-address 10.0.0.3 
set protocols bgp group internal-peers neighbor 10.0.0.1 

set protocols bgp group internal-peers neighbor 10.0.0.6 

set protocols bgp group internal-peers peer-as 65000 


Configuration on Device Ré: 


[edit] 

set routing-options autonomous-system 65000 

set protocols bgp group internal-peers type internal 

set protocols bgp group internal-peers local-address 10.0.0.6 
set protocols bgp group internal-peers neighbor 10.0.0.1 

set protocols bgp group internal-peers neighbor 10.0.0.3 

set protocols bgp group internal-peers peer-as 65000 


Step-by-Step Procedure 
To configure BGP: 


1. On each routing device, configure the local AS number. 


[edit] 
user@R1# set routing-options autonomous-system 65000 


[edit] 
user@R3# set routing-options autonomous-system 65000 


[edit] 
user@R6# set routing-options autonomous-system 65000 
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2. On each routing device, configure the internal BGP neighbor connections. 


[edit] 

user@R1# set protocols bgp group internal-peers type internal 
user@R1# set protocols bgp group internal-peers local-address 10.0.0.1 
user@R1# set protocols bgp group internal-peers neighbor 10.0.0.3 
user@R1# set protocols bgp group internal-peers neighbor 10.0.0.6 
user@R1# set protocols bgp group internal-peers peer-as 65000 


[edit] 

user@R3# set protocols bgp group internal-peers type internal 
user@R3# set protocols bgp group internal-peers local-address 10.0.0.3 
user@R3# set protocols bgp group internal-peers neighbor 10.0.0.1 
user@R3# set protocols bgp group internal-peers neighbor 10.0.0.6 
user@R3# set protocols bgp group internal-peers peer-as 65000 


[edit] 

user@R6# set protocols bgp group internal-peers type internal 
user@R6# set protocols bgp group internal-peers local-address 10.0.0.6 
user@R6# set protocols bgp group internal-peers neighbor 10.0.0.1 
user@R6# set protocols bgp group internal-peers neighbor 10.0.0.3 
user@R6# set protocols bgp group internal-peers peer-as 65000 


3. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show routing-options and show protocols bgp commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


Configuration on R1: 


user@R1# show routing-options 
autonomous-system 65000; 


user@R1# show protocols bgp 
group internal-peers { 
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type internal; 
local-address 10.0.0.1; 
peer-as 65000; 
neighbor 10.0.0.3; 
neighbor 10.0.0.6; 


Configuration on R3: 


user@R3# show routing-options 
autonomous-system 65000; 


user@R3# show protocols bgp 
group internal-peers { 
type internal; 
local-address 10.0.0.3; 
peer-as 65000; 
neighbor 10.0.0.1; 
neighbor 10.0.0.6; 


Configuration on Ré: 


user@R6# show routing-options 
autonomous-system 65000; 


user@R6# show protocols bgp 
group internal-peers { 
type internal; 
local-address 10.0.0.6; 
peer-as 65000; 
neighbor 10.0.0.1; 
neighbor 10.0.0.3; 


Configuring MPLS 


CLI Quick Configuration 


To quickly configure MPLS on all of the routing devices in AS 65000, copy the following commands and 
paste them into the CLI. 


Configuration on Device R1: 


[edit] 

set interfaces so-0/0/2 unit O family mpls 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 


Configuration on Device R3: 


[edit] 

set interfaces so-0/0/2 unit O family mpls 
set interfaces so-0/0/3 unit 0 family mpls 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 


Configuration on Device Ré: 


[edit] 

set interfaces so-0/0/3 unit O family mpls 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 


Step-by-Step Procedure 
To configure MPLS: 


1. Configure the transit interfaces for MPLS. 


[edit ] 
user@R1# set interfaces so-0/0/2 unit 0 family mpls 


[edit ] 
user@R3# set interfaces so-0/0/2 unit O family mpls 
user@R3# set interfaces so-0/0/3 unit O family mpls 


[edit ] 
user@R6# set interfaces so-0/0/3 unit O family mpls 


2. Enable MPLS. 


[edit ] 
user@R1# set protocols mpls interface all 
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[edit ] 
user@R3# set protocols mpls interface all 


[edit ] 
user@R6# set protocols mpls interface all 


3. Disable MPLS on the management interface (fxp0.0). 


[edit ] 
user@R1# set protocols mpls interface fxp0.0 disable 


[edit ] 
user@R3# set protocols mpls interface fxp0.0 disable 


[edit ] 
user@R6# set protocols mpls interface fxp0.0 disable 


4. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 

Confirm your configuration by entering the show interfaces and show protocols mpls commands. If the 
output does not display the intended configuration, repeat the instructions in this example to correct the 
configuration. 


Configuration on Device R1: 
user@R1# show interfaces 
so-0/0/2 { 


unit O { 
family mpls; 


user@R1# show protocols mpls 
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interface all; 
interface fxp0.0 { 
disable; 


Configuration on Device R3: 


user@R3# show interfaces 
so-0/0/2 { 
unit O { 
family mpls; 


} 
so-0/0/3 { 
unit O { 
family mpls; 


user@R3# show protocols mpls 
interface all; 
interface fxp0.0 { 

disable; 


Configuration on Device Ré: 


user@R6# show interfaces 
so-0/0/3 { 
unit O { 
family mpls; 


user@R6# show protocols mpls 
interface all; 
interface fxp0.0 { 

disable; 
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Configuring RSVP 


CLI Quick Configuration 
To quickly configure RSVP on all of the routing devices in AS 65000, copy the following commands and 
paste them into the CLI. 


Configuration on Device R1: 
[edit] 


set protocols rsvp interface so-0/0/2 
set protocols rsvp interface fxp0.0 disable 


Configuration on Device R3: 


[edit] 

set protocols rsvp interface so-0/0/2 

set protocols rsvp interface so-0/0/3 

set protocols rsvp interface fxp0.0 disable 


Configuration on Device R6é: 


[edit] 
set protocols rsvp interface so-0/0/3 
set protocols rsvp interface fxp0.0 disable 


Step-by-Step Procedure 
To configure RSVP: 


1. Enable RSVP. 


[edit ] 
user@R1# set protocols rsvp interface so-0/0/2 


[edit ] 
user@R3# set protocols rsvp interface so-0/0/2 
user@R3# set protocols rsvp interface so-0/0/3 


[edit ] 
user@R6# set protocols rsvp interface so-0/0/3 


2. Disable RSVP on the management interface (fxp0.0). 
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[edit ] 
user@R1# set protocols rsvp interface fxp0.0 disable 


[edit ] 
user@R3# set protocols rsvp interface fxp0.0 disable 


[edit ] 
user@R6# set protocols rsvp interface fxp0.0 disable 


3. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols rsvp command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


Configuration on Device R1: 


user@R1# show protocols rsvp 
interface so-0/0/2.0; 
interface fxp0.0 { 

disable; 


Configuration on Device R3: 


user@R3# show protocols rsvp 
interface so-0/0/2.0; 
interface so-0/0/3.0; 
interface fxp0.0 { 
disable; 


Configuration on Device R6é: 


user@R3# show protocols rsvp 
interface so-0/0/3.0; 


interface fxp0.0 { 
disable; 


Configuring OSPF 


CLI Quick Configuration 


To quickly configure OSPF, copy the following commands and paste them into the CLI. 


Configuration on Device R1: 


[edit] 

set routing-options router-id 10.0.0.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Configuration on Device R3: 


[edit] 

set routing-options router-id 10.0.0.3 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Configuration on Device Ré: 


[edit] 

set routing-options router-id 10.0.0.6 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Step-by-Step Procedure 
To configure OSPF: 


1. Configure the router ID. 


[edit] 
user@R1# set routing-options router-id 10.0.0.1 


[edit] 
user@R3# set routing-options router-id 10.0.0.3 
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[edit] 
user@R6# set routing-options router-id 10.0.0.6 


2. Configure the OSPF area and the interfaces. 


[edit] 
user@R1# set protocols ospf area 0.0.0.0 interface all 


[edit] 
user@R3# set protocols ospf area 0.0.0.0 interface all 


[edit] 
user@R6# set protocols ospf area 0.0.0.0 interface all 


3. Disable OSPF on the management interface (fxp0.0). 


[edit] 
user@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


[edit] 
user@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


[edit] 
user@R6# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


4. If you are done configuring the devices, commit the configuration. 


[edit ] 
user@host# commit 


Results 


Confirm your configuration by entering the show routing-options and the show protocols ospf commands. 
If the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


Configuration on Device R1: 
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user@R1# show routing-options 
router-id 10.0.0.1; 


user@R1# show protocols ospf 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


Configuration on Device R3: 


user@R3# show routing-options 
router-id 10.0.0.3; 


user@R3# show protocols ospf 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


Configuration on Device R6é: 


user@R6# show routing-options 
router-id 10.0.0.6; 


user@R6# show protocols ospf 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


Configuring the LSP 


CLI Quick Configuration 
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To quickly configure the LSP on the ingress routing device Router R1, copy the following command and 
paste it into the CLI. 


[edit] 
set protocols mpls label-switched-path R1-to-R6 to 10.0.0.6 


Step-by-Step Procedure 
To configure the LSP on Device R1: 


1. Enter MPLS configuration mode. 


[edit] 
user@R1# edit protocols mpls 


2. Create the LSP. 


[edit protocols mpls] 
user@R1# set label-switched-path R1-to-R6 to 10.0.0.6 


3. If you are done configuring the device, commit the configuration. 


[edit ] 
user@R1# commit 


Results 


Confirm your configuration by entering the show protocols mpls command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@R1# show protocols mpls 
label-switched-path R1-to-R6 { 
to 10.0.0.6; 


Advertising the LSP into OSPFv2 


CLI Quick Configuration 


To quickly advertise the LSP into OSPFv2 and optionally include a metric for the LSP on Device R1, copy 
the following commands and paste them into the CLI. 
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[edit] 
set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 
set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 metric 2 


Step-by-Step Procedure 
To advertise the LSP into OSPFv2 on Router R1: 


1. Enter OSPF configuration mode. 


[edit] 


user@R1# edit protocols ospf 


2. Include the label-switched-path statement, and specify the LSP R1-to-R6 that you created. 


[edit protocols ospf] 
user@R1# set area 0.0.0.0 label-switched-path R1-to-R6 


3. (Optional) Specify a metric for the LSP. 


[edit protocols ospf] 
user@R1# set protocols ospf area 0.0.0.0 label-switched-path R1-to-R6 metric 2 


4. If you are done configuring the device, commit the configuration. 


[edit] 
user@R1# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@R1# show protocols ospf 
area 0.0.0.0 { 
label-switched-path R1-to-Ré { 
metric 2; 


423 


Verification 


Confirm that the configuration is working properly. 


Verifying the OSPF Neighbor 


Purpose 


Verify that another neighbor is listed and is reachable over the LSP. The interface field indicates the name 
of the LSP. 


Action 


From operational mode, enter the show ospf neighbor command. 


Static Adjacency Segment Identifier for OSPF 


Adjacency segment is a strict forwarded single-hop tunnel that carries packets over a specific link between 
two nodes, irrespective of the link cost. You can configure static adjacency segment identifier (SID) labels 
for an interface. 


Configuring a static adjacency SID on an interface causes the existing dynamically allocated adjacency SID 
to be removed along with the transit route for the same. 


For static adjacency SIDs, the labels are picked from either a static reserved label pool or from an OSPF 
segment routing global block (SRGB). 


You can reserve a label range to be used for static allocation of labels using the following configuration: 
user@host# set protocols mpls label-range static-label-range start-value end-value 


The static pool can be used by any protocol to allocate a label in this range. You need to ensure that no 
two protocols use the same static label. OSPF adjacency SIDs can be allocated from this label block through 
the configuration using keyword label. The label value for the specific adjacency SIDs need to be explicitly 
configured. The following is a sample configuration: 


user@host# set protocols mpls label-range static-label-range 700000 799999; 
user@host# set protocols ospf source-packet-routing srgb start-label 800000 index-range 4000; 


user@host# set protocols ospf areaO interface ge-0/0/0.1 ipv4-adjacency-segment unprotected label 
700001; 
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NOTE: When you use ipv4-adjacency-segment command, the underlying interface must be 
point-to-point. 


SRGB is a global label space that is allocated for the protocol based on configuration. The labels in the 
entire SRGB is available for OSPF to use and are not allocated to other applications/protocols. Prefix SIDs 
(and Node SIDs) are indexed from this SRGB. 


OSPF Adj-SIDs can be allocated from OSPF SRGB using keyword ‘index’ in the configuration. In such cases, 
it should be ensured that the Adj-SID index does not conflict with any other prefix SID in the domain. Like 
Prefix-SIDs, Adj-SIDs will also be configured by mentioning the index with respect to the SRGB. However, 
the Adj-SID subtlv will still have the SID as a value and the L and V flags are set. The following is a sample 
configuration: 


user@host# set protocols ospf source-packet-routing srgb start-label 800000 index-range 4000; 


user@host# set protocols ospf areaO interface ge-0/0/0.1 ipv4-adjacency-segment unprotected index 
1; 


Static adjacency SIDs can be configured per area and also based on whether the protection is required or 
not. Adjacency SIDs should be configured per interface at the [edit protocols ospf area area interface 
interface-name] hierarchy level. 


e Protected—Ensures adjacency SID is eligible to have a backup path and a B-flag is set in an adjacency 
SID advertisement. 


e Unprotected—Ensures no backup path is calculated for a specific adjacency SID and a B-flag is not set 
in an adjacency SID advertisement. 


The following is a sample configuration: 


user@host# set protocols ospf areaO interface ge-0/0/0.1 ipv4-adjacency-segment unprotected index 
1; 


user@host# set protocols ospf areaO interface ge-0/0/1.1 ipv4-adjacency-segment protected index 2; 


When segment routing is used in LAN subnetworks, each router in the LAN may advertise the adjacency 
SID of each of its neighbors. To configure adjacency SID for a LAN interface to a specific neighbor, you 
should configure the adjacency SIDs under the lan-neighbor configuration at the [edit protocols ospf areaO 
interface interface_name lan-neighbor neighbor-routerid] hierarchy level. The following is a sample 
configuration: 


user@host# set protocols mpls label-range static-label-range 700000 799999; 
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user@host# set protocols ospf source-packet-routing srgb start-label 800000 index-range 4000; 


user@host# set protocols ospf areaO interface ge-1/0/0.1 lan-neighbor 11.12.1.2 ipv4-adjacency-segment 
unprotected label 700001; 


Use the following CLI hierarchy for configuring adjacency SID: 


[edit ] 
protocols { 
ospf { 
areaO { 
interface <interface_name> { 
ipv4-adjacency-segment { 
protected { 
dynamic; 
label <value> 
index <index> 
} 
unprotected { 
dynamic; 
label <value> 
index <index> 


} 
interface <interface_name> { 
lan-neighbor <neighbor-routerid>{ 
ipv4-adjacency-segment { 
protected { 
dynamic; 
label <value> 
index <index> 
} 
unprotected { 
dynamic; 
label <value> 
index <index> 
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Use the following operational CLI commands to verify the configuration: 


show ospf neighbor detail 


The following sample output displays the details of configured and dynamic adjacency SID. 


user@host> show ospf neighbor detail 


Address Interface State ID Pri Dead 
il, Wee i 2 ge-1/0/0.0 iol AL 12. oi1.4 ze) 34 
Mass: OO.0.0, oie O52, De O.0.0.0, Bor @.0.,0.0 
Up 0006277. advacent O006227 
SPRING Adjacency Labels: 


Label Flags Adj-Sid-Type 
90010 BVLP Protected 
Le VLP UnProtected 


regress@10.49.129.231# run show route label 90010 


mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


90010 * [L-OSPF/10/5] 00:00:21, metric 0 
> to 11,12.1,2 wia ge-1/0/0.,0, Pop 
t@ 11,12.2.2 wila ge-l/0/2.0, Sue 16021 
te Ii ,12.3.2 wla ge-1/0/3.0, Swe 16021 
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| Understanding Source Packet Routing in Networking (SPRING) 


Source packet routing or segment routing is a control-plane architecture that enables an ingress router to 
steer a packet through a specific set of nodes and links in the network without relying on the intermediate 
nodes in the network to determine the actual path it should take. In this context, the term ’source’ means 
‘the point at which the explicit route is imposed’. Starting with Junos OS Release 17.2R1, segment routing 
for IS-IS and OSPFv2 is supported on QFX5100 and QFX10000 switches. 


Starting with Junos OS Release 17.3R1, segment routing for IS-IS and OSPFv2 is supported on QFX5110 
and QFX5200 switches. 


Essentially segment routing engages IGPs like IS-IS and OSPF for advertising two types of network segments 
or tunnels: 


e First, a strict forwarded single-hop tunnel that carries packets over a specific link between two nodes, 
irrespective of the link cost, referred to as adjacency segments. 


e Second, a multihop tunnel using shortest path links between two specific nodes, referred to as node 
segments. 


Ingress routers can steer a packet through a desired set of nodes and links by pre-appending the packet 
with an appropriate combination of tunnels. 


Segment routing leverages the source routing paradigm. A node steers a packet through an ordered list 
of instructions, called segments. A segment can represent any instruction, topological or service-based. A 
segment can have a local semantic to a segment routing node or to a global node within a segment routing 
domain. Segment routing enforces a flow through any topological path and service chain while maintaining 
per-flow state only at the ingress node to the segment routing domain. Segment routing can be directly 
applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an 
MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the 
top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment 
routing can be applied to the IPv6 architecture, with a new type of routing extension header. A segment 
is encoded as an IPvé6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses 
in the routing extension header. The segment to process is indicated by a pointer in the routing extension 
header. Upon completion of a segment, the pointer is incremented. 


Traffic engineering shortcuts are enabled for labeled IS-IS segment routes, when you configure shortcuts 
at the following hierarchy levels: 


e [edit protocols is-is traffic-engineering family inet] for |Pv4 traffic. 


e [edit protocols is-is traffic-engineering family inet6] for IPvé traffic. 


When source packet routing is deployed in the network, the data center, backbone, and peering devices, 
switch MPLS packets with a label stack built by the source of the traffic; for example, data center servers. 
In Junos OS Release 17.4R1, the source-routed traffic co-exists with traffic taking RSVP signaled paths, 

and source routing is implemented as regular label switching through mpls.0 table using the label operations 


- pop, swap (to the same label value), and swap-push (for interface protection). In all the cases, traffic can 
be load balanced between multiple Layer 3 interfaces, or within an aggregate interface. Starting in Junos 
OS Release 17.4R1, the traffic statistics in a segment routing network can be recorded in an OpenConfig 
compliant format for the Layer 3 interfaces. The statistics is recorded for the Source Packet Routing in 
Networking (SPRING) traffic only, excluding RSVP and LDP-signaled traffic, and the family MPLS statistics 
per interface is accounted for separately. The SR statistics also includes SPRING traffic statistics per link 
aggregation group (LAG) member, and per segment identifier (SID). To enable recording of segment routing 
statistics, include sensor-based-stats statement at the [edit protocol isis source-packet-routing] hierarchy 
level. 


Prior to Junos OS Release 19.1R1, sensors were available for collecting segment routing statistics for MPLS 
transit traffic only, which is MPLS-to-MPLS in nature. Starting in Junos OS Release 19.1R1, on MX Series 
routers with MPC and MIC interfaces and PTX Series routers, additional sensors are introduced to collect 
segment routing statistics for MPLS ingress traffic, which is IP-to-MPLS in nature. With this feature, you 
can enable sensors for label IS-IS segment routing traffic only, and stream the statistics to a gRPC client. 


You can enable the segment routing statistics for MPLS ingress traffic using the egress option under the 
per-sid configuration statement. The resource name for the per-sid egress functionality is: 


/junos/services/segment-routing/sid/egress/usage/ 


You can view the label IS-IS route association with the sensors using the show isis spring sensor info command 
output. This command does not display counter values of the actual sensors. 


The segment routing statistics records are exported to a server. You can view segment routing statistics 


data from the following the OpenConfig paths: 
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NOTE: 
e Graceful Routing Engine switchover (GRES) is not supported for segment routing statistics. 


Nonstop active routing (NSR) is not supported for label IS-IS. During a Routing Engine 
switchover, a new sensor is created in the new master Routing Engine, replacing the sensor 
created by the previous master Routing Engine. As a result, at the time of a Routing Engine 
switchover, the segment routing statistics counter start from zero. 


Graceful restart is not support for label IS-IS. 


In case of graceful restart, the existing sensor is deleted and a new sensor is created during 
IS-IS initialization. The segment routing statistics counter restarts from zero. 


In-service software upgrade (ISSU) and nonstop software upgrade (NSSU) are not supported. 
In such cases, the segment routing statistics counter is restarted. 


Zero-statistics segment routing data is suppresses and does not get streamed to the gRPC 


clients. 


SEE ALSO 


IS-IS Extensions to Support Traffic Engineering 
Understanding Forwarding Adjacencies 
Understanding LDP-IGP Synchronization 
node-segment (Protocols OSPF) | 706 
no-advertise-adjacency-segment (Protocols OSPF) | 693 
no-source-packet-routing (Protocols OSPF) | 700 
per-sid 

sensor-based-stats 

sensor (Junos Telemetry Interface) 
sensor-based-stats (Junos Telemetry Interface) 

show (ospf | ospf3) overview | 855 

show (ospf | ospf3) neighbor | 848 

show ospf database | 819 

show (ospf | ospf3) route | 862 

show route table 


level (Global IS-IS) 





show isis database 
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show isis overview 

show isis route 

show isis adjacency 

source-packet-routing (Protocols IS-IS and OSPF) 
node-segment (Protocols IS-!S) 
no-advertise-adjacency-segment (Protocols |S-!S) 


use-source-packet-routing (Protocols IS-IS) 





Release History Table 


Release Description 


19.1R1 Starting in Junos OS Release 19.1R1, on MX Series routers with MPC and MIC interfaces and 
PTX Series routers, additional sensors are introduced to collect segment routing statistics for 
MPLS ingress traffic, which is IP-to-MPLS in nature. With this feature, you can enable sensors 
for label IS-IS segment routing traffic only, and stream the statistics to a gRPC client. 


17.4R1 Starting in Junos OS Release 17.4R1, the traffic statistics in a segment routing network can be 
recorded in an OpenConfig compliant format for the Layer 3 interfaces. 


17:3R1 Starting with Junos OS Release 17.3R1, segment routing for IS-IS and OSPFv2 is supported on 
QFX5110 and QFX5200 switches. 


47.2R1 Starting with Junos OS Release 17.2R1, segment routing for IS-IS and OSPFv2 is supported on 
QFX5100 and QFX10000 switches. 


RELATED DOCUMENTATION 


For more information about traffic engineering, see the MPLS Applications User Guide. 
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| OSPF Database Protection Overview 


OSPF database protection allows you to limit the number of link-state advertisements (LSAs) not generated 
by the local router in a given OSPF routing instance, helping to protect the link-state database from being 
flooded with excessive LSAs. This feature is particularly useful if VPN routing and forwarding is configured 
on your provider edge and customer edge routers using OSPF as the routing protocol. An overrun link-state 
database on the customer edge router can exhaust resources on the provider edge router and impact the 
rest of the service provider network. 


When you enable OSPF database protection, the maximum number of LSAs you specify includes all LSAs 
whose advertising router ID is not equal to the local router ID (nonself-generated LSAs). These might 
include external LSAs as well as LSAs with any scope such as the link, area, and autonomous system (AS). 


Once the specified maximum LSA count is exceeded, the database typically enters into the ignore state. 
In this state, all neighbors are brought down, and nonself-generated LSAs are destroyed. In addition, the 
database sends out hellos but ignores all received packets. As a result, the database does not form any full 
neighbors, and therefore does not learn about new LSAs. However, if you have configured the warning-only 
option, only a warning is issued and the database does not enter the ignore state but continues to operate 
as before. 


You can also configure one or more of the following options: 


e A warning threshold for issuing a warning message before the LSA limit is reached. 


e Anignore state time during which the database must remain in the ignore state and after which normal 
operations can be resumed. 


e Anignore state count that limits the number of times the database can enter the ignore state, after 
which it must enter the isolate state. The isolate state is very similar to the ignore state, but has one 
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important difference: once the database enters the isolate state, it must remain there until you issue a 
command to clear database protection before it can return to normal operations. 


e Areset time during which the database must stay out of the ignore or isolate state before it is returned 
to a normal operating state. 


SEE ALSO 


| database-protection | 627 


Configuring OSPF Database Protection 


By configuring OSPF database protection, you can help prevent your OSPF link-state database from being 
overrun with excessive LSAs that are not generated by the local router. You specify the maximum number 
of LSAs whose advertising router ID is not the same as the local router ID in an OSPF instance. This feature 
is particularly useful if your provider edge and customer edge routers are configured with VPN routing 
and forwarding using OSPF. 


OSPF database protection is supported on: 


e Logical systems 

e All routing instances supported by OSPFv2 and OSPFv3 
e OSPFv2 and OSPFv3 topologies 

e OSPFv3 realms 


To configure OSPF database protection: 


1. Include the database-protection statement at one of the following hierarchy levels: 
e [edit protocols ospf | ospf3] 


e [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf 
Jospf3)] 


e [edit routing-instances routing-instance-name protocols (ospf |ospf3)] 


e [edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast 
| ipv6-unicast | ipv6-multicast)] 


2. Include the maximum-lsa number statement. 
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NOTE: The maximum-lsa statement is mandatory, and there is no default value for it. If you 
omit this statement, you cannot configure OSPF database protection. 


3. (Optional) Include the following statements: 


ignore-count number—Specify the number of times the database can enter the ignore state before 


it goes into the isolate state. 


ignore-time seconds—Specify the time limit the database must remain in the ignore state before it 


resumes regular operations. 


reset-time seconds—Specify the time during which the database must operate without being in either 


the ignore or isolate state before it is reset to a normal operating state. 


warning-threshold percent—Specify the percent of the maximum LSA number that must be exceeded 
before a warning message is issued. 


4. (Optional) Include the warning-only statement to prevent the database from entering the ignore state 
or isolate state when the maximum LSA count is exceeded. 


NOTE: If you include the warning-only statement, values for the other optional statements 


at the same hierarchy level are not used when the maximum LSA number is exceeded. 


5. Verify your configuration by checking the database protection fields in the output of the show ospf 
overview command. 


RELATED DOCUMENTATION 


database-protection | 627 
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For some routing platform vendors, the flow of routes occurs between various protocols. If, for example, 
you want to configure redistribution from RIP to OSPF, the RIP process tells the OSPF process that it has 
routes that might be included for redistribution. In Junos OS, there is not much direct interaction between 
the routing protocols. Instead, there are central gathering points where all protocols install their routing 
information. These are the main unicast routing tables inet.O and inet6.0. 


From these tables, the routing protocols calculate the best route to each destination and place these routes 
in a forwarding table. These routes are then used to forward routing protocol traffic toward a destination, 
and they can be advertised to neighbors. 


Importing and Exporting Routes 


Two terms—import and export—explain how routes move between the routing protocols and the routing 
table. 


e When the Routing Engine places the routes of a routing protocol into the routing table, it is importing 
routes into the routing table. 


e When the Routing Engine uses active routes from the routing table to send a protocol advertisement, 
it is exporting routes from the routing table. 


NOTE: The process of moving routes between a routing protocol and the routing table is 
described always from the point of view of the routing table. That is, routes are imported into a 
routing table from a routing protocol and they are exported from a routing table to a routing 
protocol. Remember this distinction when working with routing policies. 


As shown in Figure 25 on page 438, you use import routing policies to control which routes are placed in 
the routing table, and export routing policies to control which routes are advertised from the routing table 
to neighbors. 
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Figure 25: Importing and Exporting Routes 
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In general, the routing protocols place all their routes in the routing table and advertise a limited set of 
routes from the routing table. The general rules for handling the routing information between the routing 
protocols and the routing table are known as the routing policy framework. 


The routing policy framework is composed of default rules for each routing protocol that determine which 
routes the protocol places in the routing table and advertises from the routing table. The default rules for 
each routing protocol are known as default routing policies. 


You can create routing policies to preempt the default policies, which are always present. A routing policy 
allows you to modify the routing policy framework to suit your needs. You can create and implement your 
own routing policies to do the following: 


e Control which routes a routing protocol places in the routing table. 


e Control which active routes a routing protocol advertises from the routing table. An active route is a 
route that is chosen from all routes in the routing table to reach a destination. 


e Manipulate the route characteristics as a routing protocol places the route in the routing table or advertises 
the route from the routing table. 


You can manipulate the route characteristics to control which route is selected as the active route to reach 
a destination. The active route is placed in the forwarding table and is used to forward traffic toward the 
route’s destination. In general, the active route is also advertised to a router’s neighbors. 


Active and Inactive Routes 


When multiple routes for a destination exist in the routing table, the protocol selects an active route and 
that route is placed in the appropriate routing table. For equal-cost routes, the Junos OS places multiple 
next hops in the appropriate routing table. 


When a protocol is exporting routes from the routing table, it exports active routes only. This applies to 
actions specified by both default and user-defined export policies. 
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When evaluating routes for export, the Routing Engine uses only active routes from the routing table. For 
example, if a routing table contains multiple routes to the same destination and one route has a preferable 
metric, only that route is evaluated. In other words, an export policy does not evaluate all routes; it evaluates 
only those routes that a routing protocol is allowed to advertise to a neighbor. 


NOTE: By default, BGP advertises active routes. However, you can configure BGP to advertise 
inactive routes, which go to the same destination as other routes but have less preferable metrics. 


Explicitly Configured Routes 


An explicitly configured route is a route that you have configured. Direct routes are not explicitly configured. 
They are created as a result of IP addresses being configured on an interface. Explicitly configured routes 
include aggregate, generated, local, and static routes. (An aggregate route is a route that distills groups of 
routes with common addresses into one route. A generated route is a route used when the routing table 
has no information about how to reach a particular destination. A local route is an IP address assigned to 
a router interface. A static route is an unchanging route to a destination.) 


The policy framework software treats direct and explicitly configured routes as if they are learned through 
routing protocols; therefore, they can be imported into the routing table. Routes cannot be exported from 
the routing table to the pseudoprotocol, because this protocol is not a real routing protocol. However, 
aggregate, direct, generated, and static routes can be exported from the routing table to routing protocols, 
whereas local routes cannot. 


Dynamic Database 


In Junos OS Release 9.5 and later, you can configure routing policies and certain routing policy objects in 
a dynamic database that is not subject to the same verification required by the standard configuration 
database. As a result, you can quickly commit these routing policies and policy objects, which can be 
referenced and applied in the standard configuration as needed. BGP is the only protocol to which you 
can apply routing policies that reference policies configured in the dynamic database. After a routing policy 
based on the dynamic database is configured and committed in the standard configuration, you can quickly 
make changes to existing routing policies by modifying policy objects in the dynamic database. Because 
Junos OS does not validate configuration changes to the dynamic database, when you use this feature, 
you should test and verify all configuration changes before committing them. 


SEE ALSO 


Example: Configuring Dynamic Routing Policies 
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| Understanding OSPF Routing Policy 
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@ Routing Policy Match Conditions | 441 
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Each routing policy is identified by a policy name. The name can contain letters, numbers, and hyphens (-) 
and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double 
quotation marks. Each routing policy name must be unique within a configuration. Once a policy is created 
and named, it must be applied before it is active. 


In the import statement, you list the name of the routing policy used to filter OSPF external routes from 
being installed into the routing tables of OSPF neighbors. You can filter the routes, but not link-state 
address (LSA) flooding. An external route is a route that is outside the OSPF Autonomous System (AS). 
The import policy does not impact the OSPF database. This means that the import policy has no impact 
on the link-state advertisements. 


In the export statement, you list the name of the routing policy to be evaluated when routes are being 
exported from the routing table into OSPF. 


By default, if a routing device has multiple OSPF areas, learned routes from other areas are automatically 
installed into area O of the routing table. 


To specify more than one policy and create a policy chain, you list the policies using a space as a separator. 
If multiple policies are specified, the policies are evaluated in the order in which they are specified. As soon 
as an accept or reject action is executed, the policy chain evaluation ends. 


This topic describes the following information: 


Routing Policy Terms 


Routing policies are made up of one or more terms. A term is anamed structure in which match conditions 
and actions are defined. You can define one or more terms. The name can contain letters, numbers, and 
hyphens ( - ) and can be up to 255 characters long. To include spaces in the name, enclose the entire name 
in double quotation marks. 
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Each term contains a set of match conditions and a set of actions: 


e Match conditions are criteria that a route must match before the actions can be applied. If a route 
matches all criteria, one or more actions are applied to the route. 


e Actions specify whether to accept or reject the route, control how a series of policies are evaluated, and 
manipulate the characteristics associated with a route. 


Routing Policy Match Conditions 


A match condition defines the criteria that a route must match for an action to take place. You can define 
one or more match conditions for each term. If a route matches all of the match conditions for a particular 
term, the actions defined for that term are processed. 


Each term can include two statements, from and to, that define the match conditions: 


In the from statement, you define the criteria that an incoming route must match. You can specify one 
or more match conditions. If you specify more than one, they all must match the route for a match to 


occur. 


The from statement is optional. If you omit the from and the to statements, all routes are considered to 
match. 


NOTE: In export policies, omitting the from statement from a routing policy term might lead 
to unexpected results. 


e Inthe to statement, you define the criteria that an outgoing route must match. You can specify one or 
more match conditions. If you specify more than one, they all must match the route for a match to occur. 


The order of the match conditions in a term is not important because a route must match all match conditions 
in a term for an action to be taken. 


For a complete list of match conditions, see Configuring Match Conditions in Routing Policy Terms. 


Routing Policy Actions 


An action defines what the routing device does with the route when the route matches all the match 
conditions in the from and to statements for a particular term. If a term does not have from and to 
statements, all routes are considered to match and the actions apply to all routes. 


Each term can have one or more of the following types of actions. The actions are configured under the 
then statement. 


e Flow control actions, which affect whether to accept or reject the route and whether to evaluate the 
next term or routing policy. 
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e Actions that manipulate route characteristics. 


e Trace action, which logs route matches. 
The then statement is optional. If you omit it, one of the following occurs: 


e The next term in the routing policy, if one exists, is evaluated. 
e If the routing policy has no more terms, the next routing policy, if one exists, is evaluated. 


e If there are no more terms or routing policies, the accept or reject action specified by the default policy 
is executed. 


For a complete list of routing policy actions, see Configuring Actions in Routing Policy Terms. 


Understanding Backup Selection Policy for OSPF Protocol 


Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF. 
Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are 
pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup 
path when the link for a primary next hop for a particular route is no longer available. The selection of LFA 
is done randomly by selecting any matching LFA to progress to the given destination. This does not ensure 
best backup coverage available for the network. In order to choose the best LFA, Junos OS allows you to 
configure network-wide backup selection policies for each destination (IPv4 and IPvé6) and a primary 
next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth, protection-type, 
metric, and node information. 


During backup shortest-path-first (SPF) computation, each node and link attribute of the backup path is 
accumulated by IGP and is associated with every node (router) in the topology. The next hop in the best 
backup path is selected as the backup next hop in the routing table. In general, backup evaluation policy 
rules are categorized into the following types: 


e Pruning — Rules configured to select the eligible backup path. 


e Ordering — Rules configured to select the best among the eligible backup paths. 


The backup selection policies can be configured with both pruning and ordering rules. While evaluating 
the backup policies, each backup path is assigned a score, an integer value that signifies the total weight 
of the evaluated criteria. The backup path with the highest score is selected. 


To enforce LFA selection, configure various rules for the following attributes: 


admin-group- Administrative groups, also known as link coloring or resource class, are manually assigned 
attributes that describe the “color” of links, such that links with the same color conceptually belong to 
the same class. These configured administrative groups are defined under protocol MPLS. You can use 
administrative groups to implement a variety of backup selection policies using exclude, include-all, 
include-any, or preference. 


srlg— A shared risk link group (SRLG) is a set of links sharing a common resource, which affects all links 
in the set if the common resource fails. These links share the same risk of failure and are therefore 
considered to belong to the same SRLG. For example, links sharing a common fiber are said to be in the 
same SRLG because a fault with the fiber might cause all links in the group to fail. An SRLG is represented 
by a 32-bit number unique within an IGP (OSPF) domain. A link might belong to multiple SRLGs. You 
can define the backup selection to either allow or reject the common SRLGs between the primary and 
the backup path. This rejection of common SRLGs are based on the non-existence of link having common 
SRLGs in the primary next-hop and the backup SPF. 


NOTE: Administrative groups and SRLGs can be created only for default topologies. 


bandwidth—The bandwidth specifies the bandwidth constraints between the primary and the backup 
path. The backup next-hop link can be used only if the bandwidth of the backup next-hop interface is 
greater than or equal to the bandwidth of the primary next hop. 


protection-type— The protection-type protects the destination from node failure of the primary node 
or link failure of the primary link. You can configure node, link, or node-link to protect the destination. 
If link-node is configured , then the node-protecting LFA is preferred over link-protection LFA. 


node- The node is per-node policy information. Here, node can be a directly connected router, remote 
router like RSVP backup LSP tail-end, or any other router in the backup SPF path. The nodes are identified 
through the route-id advertised by a node in the LSP. You can list the nodes to either prefer or exclude 
them in the backup path. 


metric— Metric decides how the LFAs should be preferred. In backup selection path, root metric and 
dest-metric are the two types of metrics. root-metric indicates the metric to the one-hop neighbor or a 
remote router such as an RSVP backup LSP tail-end router. The dest-metric indicates the metric froma 
one-hop neighbor or remote router such as an RSVP backup LSP tail-end router to the final destination. 
The metric evaluation is done either in ascending or descending order. By default, the first preference 
is given to backup paths with lowest destination evaluation and then to backup paths with lowest root 
metrics. 


The evaluation-order allows you to control the order and criteria of evaluating these attributes in the 


backup path. You can explicitly configure the evaluation order. Only the configured attributes influence 


the backup path selection. The default order of evaluation of these attributes for the LFA is [ admin-group 


srlg bandwidth protection-type node metric ] . 
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NOTE: TE attributes are not supported in OSPFv3 and cannot be used for backup selection 
policy evaluation for IPvé6 prefixes. 


SEE ALSO 


| backup-selection (Protocols ISIS) 


Configuring Backup Selection Policy for the OSPF Protocol 


Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF. 
Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are 
pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup 
path when the link for a primary next hop for a particular route is no longer available. The selection of LFA 
is done randomly by selecting any matching LFA to progress to the given destination. This does not ensure 
best backup coverage available for the network. In order to choose the best LFA, Junos OS allows you to 
configure network-wide backup selection policies for each destination (IPv4 and IPvé6) and a primary 
next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth, protection-type, 
metric, and node information. 


Before you begin to configure the backup selection policy for the OSPF protocol: 


e Configure the router interfaces. See the Junos OS Network Management Administration Guide for Routing 
Devices. 


e Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for 
Routing Devices. 


To configure the backup selection policy for the OSPF protocol: 


1. Configure per-packet load balancing. 


[edit policy-options] 
user@host# set policy-statement ecmp term 1 then load-balance per-packet 


2. Enable RSVP on all the interfaces. 


[edit protocols] 


user@host# set rsvp interface all 


. Configure administrative groups. 


[edit protocols mpls] 
user@host# set admin-groups group-name 


. Configure srlg values. 


[edit routing-options] 
user@host# set srlg srlg-name srlg-value srlg-value 


. Enable MPLS on all the interfaces. 


[edit protocols mpls] 
user@host# set interface all 


. Apply MPLS to an interface configured with an administrative group. 


[edit protocols mpls] 
user@host# set interface interface-name admin-group group-name 


. Configure the ID of the router. 


[edit routing-options] 
user@host# set router-id router-id 


. Apply the routing policy to all equal cost multipaths exported from the routing table to the forwarding 


table. 


[edit routing-options] 
user@host# set forwarding-table export ecmp 


. Enable link protection and configure metric values on all the interfaces for an area. 


[edit protocols ospf] 
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user@host# set area area-id interface interface-name link-protection 
user@host# set area area-id interface interface-name metric metric 


10. Configure the administrative group of the backup selection policy for an IP address. 


You can choose to exclude, include all, include any, or prefer the administrative groups from the backup 
path. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name admin-group 


e Specify the administrative group to be excluded. 


[edit routing-options backup-selection destination ip-address interface interface-name admin-group] 
user@host# set exclude group-name 


The backup path is not selected as the loop-free alternate (LFA) or backup nexthop if any of the links 
in the path have any one of the listed administrative groups. 


For example, to exclude the group c1 from the administrative group: 


[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group] 
user@host# set exclude c1 


e Configure all the administrative groups if each link in the backup path requires all the listed 
administrative groups in order to accept the path. 


[edit routing-options backup-selection destination ip-address interface interface-name admin-group] 
user@host# set include-all group-name 


For example, to set all the administrative groups if each link requires all the listed administrative 
groups in order to accept the path: 


[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group] 
user@host# set include-all c2 


e Configure any administrative group if each link in the backup path requires at least one of the listed 
administrative groups in order to select the path. 


[edit routing-options backup-selection destination ip-address interface interface-name admin-group] 
user@host# set include-any group-name 
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For example, to set any administrative group if each link in the backup path requires at least one of 
the listed administrative groups in order to select the path: 


[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group] 
user@host# set include-any c3 
e Define an ordered set of an administrative group that specifies the preference of the backup path. 
The leftmost element in the set is given the highest preference. 


[edit routing-options backup-selection destination ip-address interface interface-name admin-group] 
user@host# set preference group-name 


For example, to set an ordered set of an administrative group that specifies the preference of the 
backup path: 


[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group] 
user@host# set preference c4 


11. Configure the backup path to allow the selection of the backup next hop only if the bandwidth is greater 
than or equal to the bandwidth of the primary next hop. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name 
bandwidth-greater-equal-primary 


12. Configure the backup path to specify the metric from the one-hop neighbor or from the remote router 
such as an RSVP backup label-switched-path (LSP) tail-end router to the final destination. 


The destination metric can be either highest or lowest. 


e Configure the backup path that has the highest destination metric. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name dest-metric highest 


e Configure the backup path that has the lowest destination metric. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name dest-metric lowest 


13. Configure the backup path that is a downstream path to the destination. 
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[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name downstream-paths-only 


14. Set the order of preference of the root and the destination metric during backup path selection. 
The preference order can be: 


e [root dest] — Backup path selection or preference is first based on the root-metric criteria. If the 
criteria of all the root-metric is the same, then the selection or preference is based on the dest- metric. 


e [dest root] — Backup path selection or preference is first based on the dest-metric criteria. If the 
criteria of all the dest-metric is the same, then the selection is based on the root-metric. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name metric-order dest 
user@host# set backup-selection destination ip-address interface interface-name metric-order root 


15. Configure the backup path to define a list of loop-back IP addresses of the adjacent neighbors to either 
exclude or prefer in the backup path selection. 


The neighbor can be a local (adjacent router) neighbor, remote neighbor, or any other router in the 
backup path. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name node 


e Configure the list of neighbors to be excluded. 


[edit routing-options backup-selection destination ip-address interface interface-name node] 
user@host# set exclude node-address 


The backup path that has a router from the list is not selected as the loop-free alternative or backup 
next hop. 


e Configure an ordered set of neighbors to be preferred. 


[edit routing-options backup-selection destination ip-address interface interface-name node] 
user@host# set preference node-address 


The backup path having the leftmost neighbor is selected. 


16. Configure the backup path to specify the required protection type of the backup path to be link, node, 
or node-link. 


e Select the backup path that provides link protection. 


449 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name protection-type link 


e Select the backup path that provides node protection. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name protection-type node 


e Select the backup path that allows either node or link protection LFA where node-protection LFA is 
preferred over link-protection LFA. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface interface-name protection-type node-link 


17. Specify the metric to the one-hop neighbor or to the remote router such as an RSVP backup 
label-switched-path (LSP) tail-end router. 


e Select the path with highest root metric. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface all root-metric highest 


e Select the path with lowest root metric. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface all root-metric lowest 


18. Configure the backup selection path to either allow or reject the common shared risk link groups (SRLGs) 
between the primary link and each link in the backup path. 


e Configure the backup path to allow common srlgs between the primary link and each link in the 
backup path. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface all srlg loose 


A backup path with a fewer number of srlg collisions is preferred. 


e Configure the backup path to reject the backup path that has common srlgs between the primary 
next-hop link and each link in the backup path. 


[edit routing-options] 
user@host# set backup-selection destination ip-address interface all srlg strict 
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19. Configure the backup path to control the order and the criteria of evaluating the backup path based 
on the administrative group, srlg, bandwidth, protection type, node, and metric. 


The default order of evaluation is admin-group, srlg, bandwidth, protection-type, node, and metric. 


[edit routing-options] 

user@host# set backup-selection destination ip-address interface all evaluation-order admin-group 
user@host# set backup-selection destination ip-address interface all evaluation-order srlg 
user@host# set backup-selection destination ip-address interface all evaluation-order bandwidth 


SEE ALSO 


| backup-selection (Protocols ISIS) 


Topology-Independent Loop-Free Alternate with Segment Routing for 
OSPF 


IN THIS SECTION 


@ Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 450 
® Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 452 


Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF 


IN THIS SECTION 


@ = Benefits of Using Topology-Independent Loop-Free Alternate with Segment Routing | 452 


Segment routing enables a router to send a packet along a specific path in the network by imposing a label 
stack that describes the path. The forwarding actions described by a segment routing label stack do not 
need to be established on a per-path basis. Therefore, an ingress router can instantiate an arbitrary path 
using a segment routing label stack and use it immediately without any signaling. 


In segment routing, each node advertises mappings between incoming labels and forwarding actions. A 
specific forwarding action is referred to as a segment and the label that identifies that segment is referred 
to as a segment identifier (SID). The backup paths created by TI-LFA use the following types of segments: 


e Node segment—A node segment forwards packets along the shortest path or paths to a destination 
node. The label representing the node segment (the node SID) is swapped until the destination node is 
reached. 


e Adjacency segment—An adjacency segment forwards packets across a specific interface on the node 
that advertised the adjacency segment. The label representing an adjacency segment (the adjacency 
SID) is popped by the node that advertised it. 


A router can send a packet along a specific path by creating a label stack that uses a combination of node 
SIDs and adjacency SIDs. Typically, node SIDs are used to represent parts of the path that correspond to 
the shortest path between two nodes. An adjacency SID is used wherever a node SID cannot be used to 
accurately represent the desired path. 


When used with OSPF, TI-LFA provides protection against link failure and node failure. In link failure mode, 
the destination is protected if the link fails. In node protection mode, the destination is protected if the 
neighbor connected to the primary link fails. To determine the node-protecting post-convergence path, 
the cost of all the links leaving the neighbor is assumed to increase by a configurable amount. 


In order to construct a backup path that follows the post-convergence path, TI-LFA can use several labels 
in the label stack that define the backup path. If the number of labels required to construct a particular 
post-convergence backup path exceeds a certain amount, it is useful in some circumstances to not install 
that backup path. You can configure the maximum number of labels that a backup path can have in order 
to be installed. The default value is 3, with a range of 2 through 5. 


It is often the case that the post-convergence path for a given failure is actually a set of equal-cost paths. 
TI-LFA attempts to construct the backup paths to a given destination using multiple equal-cost paths in 
the post-failure topology. Depending on the topology, TI-LFA might need to use different label stacks to 
accurately construct those equal-cost backup paths. By default, TI-LFA only installs one backup path for 
a given destination. However, you can configure the value in the range from 1 through 8. 
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Benefits of Using Topology-Independent Loop-Free Alternate with Segment Routing 


e Loop-free alternate (LFA) and remote LFA (RLFA) have been used to provide fast-reroute protection for 
several years. With LFA, a point of local repair (PLR) determines whether or not a packet sent to one of 
its direct neighbors reaches its destination without looping back through the PLR. In a typical network 
topology, approximately 40 to 60 percent of the destinations can be protected by LFA. Remote LFA 
expands on the concept of LFA by allowing the PLR to impose a single label to tunnel the packet to a 
repair tunnel endpoint from which the packet can reach its destination without looping back through 
the PLR. Using remote LFA, more destinations can be protected by the PLR compared to LFA. However, 
depending on the network topology, the percentage of destinations protected by remote LFA is usually 
less than 100 percent. 


e Topology-independent LFA (TI-LFA) extends the concept of LFA and remote LFA by allowing the PLR 
to use deeper label stacks to construct backup paths. In addition, TI-LFA imposes the constraint that 
the backup path used by the PLR be the same path that a packet takes once the interior gateway protocol 
(IGP) has converged for a given failure scenario. This path is referred to as the post-convergence path. 


e Using the post-convergence path as the backup path has some desirable characteristics. For some 
topologies, a network operator only needs to make sure that the network has enough capacity to carry 
the traffic along the post-convergence path after a failure. In these cases, a network operator does not 
need to allocate additional capacity to deal with the traffic pattern immediately after the failure while 
the backup path is active, because the backup path follows the post-convergence path. 


e When used with OSPF, TI-LFA provides protection against link failure and node failure. 


Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF 


Before you configure TI-LFA for OSPF, be sure you configure SPRING or segment routing. 


Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent TI-LFA 
backup paths where the prefix SID is learned from a segment routing mapping server advertisement when 
the PLR and mapping server are both in the same OSPF area. 


To configure TI-LFA using SPRING for OSPF, you must do the following: 


1. Enable TI-LFA for OSPF protocol. 


[edit protocols ospf backup-spf-options] 
user@R1# set use-post-convergence-lfa 


2. (Optional) Configure backup shortest path first (SPF) attributes such as maximum equal-cost multipath 
(ECMP) backup paths and maximum labels for TI-LFA for the OSPF protocol. 


[edit protocols ospf backup-spf-options use-post-convergence-lfa] 
user@R1# set maximum-backup-paths maximum-backup-paths 
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user@R1# set maximum-labels maximum-labels 


3. Configure the computation and installation of a backup path that follows the post-convergence path 
on the given interface and level for the OSPF protocol. 


[edit protocols ospf interface interface-name level level 
user@R1# set post-convergence-lfa 


4. (Optional) Enable node protection for a given interface and level. 


[edit protocols ospf interface interface-name level level post-convergence-lfa] 
user@R1# set node-protection 


RELATED DOCUMENTATION 
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use-post-convergence-lfa | 774 
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Example: Configuring Backup Selection Policy for the OSPF or OSPF3 
Protocol 
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This example shows how to configure the backup selection policy for the OSPF or OSPF3 protocol, which 
enables you to select a loop-free alternate (LFA) in the network. 
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When you enable backup selection policies, Junos OS allows selection of LFA based on the policy rules 
and attributes of the links and nodes in the network. These attributes are admin-group, srlg, bandwidth, 
protection-type, metric, and node. 


Requirements 


This example uses the following hardware and software components: 


e Eight routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal 
Routing Platforms, PTX Series Packet Transport Routers, and T Series Core Routers 


e Junos OS Release 15.1 or later running on all devices 
Before you begin: 


1. Configure the device interfaces. 


2. Configure OSPF. 


Overview 


In Junos OS, the default loop-free alternative (LFA) selection algorithm or criteria can be overridden with 
an LFA policy. These policies are configured for each destination (IPv4 and IPv6) and a primary next-hop 
interface . These backup policies enforce LFA selection based on admin-group, srlg, bandwidth, 
protection-type, metric, and node attributes of the backup path. During backup shortest-path-first (SPF) 
computation, each attribute (both node and link) of the backup path, stored per backup next-hop, is 
accumulated by IGP. For the routes created internally by IGP, the attribute set of every backup path is 
evaluated against the policy configured for each destination (IPv4 and IPv6) and a primary next-hop 
interface. The first or the best backup path is selected and installed as the backup next hop in the routing 
table. To configure the backup selection policy, include the backup-selection configuration statement at 
the [edit routing-options] hierarchy level. The show backup-selection command displays the configured 
policies for a given interface and destination. The display can be filtered against a particular destination, 
prefix, interface, or logical systems. 


Topology 
In this topology shown in Figure 26 on page 455, the backup selection policy is configured on Device R3. 


Figure 26: Example Backup Selection Policy for OSPF or OPSF3 
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Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


RO 


set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30 

set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:10:1:1::1/64 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/1/0 unit 0 family inet address 172.16.15.1/30 

set interfaces ge-0/1/0 unit 0 family inet6 address 2001:db8:15:1:1::1/64 
set interfaces ge-0/1/0 unit 0 family mpls 
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set interfaces xe-0/2/0 unit 0 family inet address 172.16.20.1/30 

set interfaces xe-0/2/0 unit 0 family inet6 address 2001:db8:20:1:1::1/64 
set interfaces xe-0/2/0 unit 0 family mpls 

set interfaces ge-1/0/5 unit 0 family inet address 172.16.150.1/24 

set interfaces ge-1/0/5 unit 0 family inet6 address 2001:db8:150:1:1::1/64 
set interfaces ge-1/0/5 unit 0 family mpls 

set interfaces ge-1/1/1 unit 0 family inet address 172.16.30.1/30 

set interfaces ge-1/1/1 unit 0 family inet6 address 2001:db8:30:1:1::1/64 
set interfaces ge-1/1/1 unit 0 family mpls 

set interfaces xe-1/3/0 unit 0 family inet address 172.16.25.1/30 

set interfaces xe-1/3/0 unit 0 family inet6 address 2001:db8:25:1:1::1/64 
set interfaces xe-1/3/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.10.10.10/32 primary 

set interfaces loO unit O family inet6 address 2001:db8::10:10:10:10/128 primary 
set interfaces loO unit O family mpls 

set routing-options srlg srlg1 srlg-value 1001 

set routing-options srlg srlg2 srlg-value 1002 

set routing-options srlg srlg3 srlg-value 1003 

set routing-options srlg srlg4 srlg-value 1004 

set routing-options srlg srlg5 srlg-value 1005 

set routing-options srlg srlg6 srlg-value 1006 

set routing-options srlg srlg7 srlg-value 1007 

set routing-options srlg srlg8 srlg-value 1008 

set routing-options srlg srlg9 srlg-value 1009 

set routing-options srlg srlg10 srlg-value 10010 

set routing-options srlg srlg11 srlg-value 10011 

set routing-options srlg srlg12 srlg-value 10012 

set routing-options router-id 10.10.10.10 

set protocols rsvp interface all 

set protocols mpls admin-groups cO O 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 
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set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 18 
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 51 
set protocols ospf area 0.0.0.0 interface ge-1/1/1.0 metric 23 
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 52 
set protocols ospf area 0.0.0.0 interface ge-1/0/5.0 

set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 18 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 51 
set protocols ospf3 area 0.0.0.0 interface ge-1/1/1.0 metric 23 
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 52 
set protocols ospf3 area 0.0.0.0 interface ge-1/0/5.0 


set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30 

set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:10:1:1::2/64 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/5 unit 0 family inet address 172.16.35.1/30 

set interfaces ge-0/0/5 unit 0 family inet6 address 2001:db8:35:1:1::1/64 
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set interfaces ge-0/0/5 unit 0 family mpls 

set interfaces xe-0/2/0 unit 0 family inet address 172.16.40.1/30 
set interfaces xe-0/2/0 unit 0 family inet6 address 2001:db8:40:1:1::1/64 
set interfaces xe-0/2/0 unit 0 family mpls 

set interfaces xe-0/3/0 unit 0 family inet address 172.16.45.1/30 
set interfaces xe-0/3/0 unit 0 family inet6 address 2001:db8:45:1:1::1/64 
set interfaces xe-0/3/0 unit 0 family mpls 

set interfaces loO unit O family inet address 172.16.1.1/32 primary 
set interfaces loO unit O family inet6 address 2001:db8::1:1:1:1/128 primary 
set interfaces loO unit O family mpls 

set routing-options srlg srlg1 srlg-value 1001 

set routing-options srlg srlg2 srlg-value 1002 

set routing-options srlg srlg3 srlg-value 1003 

set routing-options srlg srlg4 srlg-value 1004 

set routing-options srlg srlg5 srlg-value 1005 

set routing-options srlg srlg6 srlg-value 1006 

set routing-options srlg srlg7 srlg-value 1007 

set routing-options srlg srlg8 srlg-value 1008 

set routing-options srlg srlg9 srlg-value 1009 

set routing-options srlg srlg10 srlg-value 10010 

set routing-options srlg srlg11 srlg-value 10011 

set routing-options srlg srlg12 srlg-value 10012 

set routing-options router-id 172.16.1.1 

set protocols rsvp interface all 

set protocols mpls admin-groups cO O 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 
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set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols mpls interface ge-0/0/0.0 srlg srlg9 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 10 
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 10 


set interfaces ge-0/0/2 unit 0 family inet address 172.16.35.2/30 

set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:35:1:1::2/64 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/1/0 unit 0 family inet address 172.16.50.1/30 

set interfaces ge-0/1/0 unit 0 family inet6 address 2001:db8:50:1:1::1/64 
set interfaces ge-0/1/0 unit 0 family mpls 

set interfaces xe-0/2/1 unit 0 family inet address 172.16.55.1/30 

set interfaces xe-0/2/1 unit 0 family inet6 address 2001:db8:55:1:1::1/64 
set interfaces xe-0/2/1 unit 0 family mpls 

set interfaces ge-1/0/2 unit 0 family inet address 172.16.60.1/30 

set interfaces ge-1/0/2 unit 0 family inet6 address 2001:db8:60:1:1::1/64 
set interfaces ge-1/0/2 unit 0 family mpls 

set interfaces ge-1/0/9 unit 0 family inet address 172.16.65.1/30 
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set interfaces ge-1/0/9 unit 0 family inet6 address 2001:db8:65:1:1::1/64 
set interfaces ge-1/0/9 unit 0 family mpls 

set interfaces ge-1/1/5 unit 0 family inet address 172.16.70.1/30 
set interfaces ge-1/1/5 unit 0 family inet6 address 2001:db8:70:1:1::1/64 
set interfaces ge-1/1/5 unit 0 family mpls 

set interfaces loO unit O family inet address 172.16.2.2/32 primary 
set interfaces loO unit O family inet6 address 2001:db8::2:2:2:2/128 primary 
set interfaces loO unit O family mpls 

set routing-options srlg srig1 srlg-value 1001 

set routing-options srlg srlg2 srlg-value 1002 

set routing-options srlg srlg3 srlg-value 1003 

set routing-options srlg srlg4 srlg-value 1004 

set routing-options srlg srlg5 srlg-value 1005 

set routing-options srlg srlg6 srlg-value 1006 

set routing-options srlg srlg7 srlg-value 1007 

set routing-options srlg srlg8 srlg-value 1008 

set routing-options srlg srlg9 srlg-value 1009 

set routing-options srlg srlg10 srig-value 10010 

set routing-options srlg srlg11 srlg-value 10011 

set routing-options srlg srlg12 srlg-value 10012 

set routing-options router-id 172.16.2.2 

set protocols rsvp interface all 

set protocols mpls admin-groups cO 0 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 
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set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols mpls interface ge-0/1/0.0 srlg srlg1 

set protocols mpls interface ge-1/0/9.0 srlg srlg1 

set protocols mpls interface ge-1/1/5.0 srlg srlg7 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0 metric 12 
set protocols ospf area 0.0.0.0 interface ge-1/0/2.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-1/0/9.0 metric 12 
set protocols ospf area 0.0.0.0 interface ge-1/1/5.0 metric 13 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/2.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 link-protection 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/1.0 metric 12 
set protocols ospf3 area 0.0.0.0 interface ge-1/0/2.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-1/0/9.0 metric 12 
set protocols ospf3 area 0.0.0.0 interface ge-1/1/5.0 metric 13 


set interfaces ge-0/0/5 unit 0 family inet address 172.16.50.2/30 

set interfaces ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64 
set interfaces ge-0/0/5 unit 0 family mpls 

set interfaces xe-0/3/1 unit 0 family inet address 172.16.75.1/30 

set interfaces xe-0/3/1 unit 0 family inet6 address 2001:db8:75:1:1::1/64 
set interfaces xe-0/3/1 unit 0 family mpls 

set interfaces ge-1/0/0 unit 0 family inet address 172.16.80.1/30 

set interfaces ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64 
set interfaces ge-1/0/0 unit 0 family mpls 
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set interfaces ge-1/0/5 unit 0 family inet address 172.16.200.1/24 

set interfaces ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64 

set interfaces ge-1/0/6 unit 0 family inet address 172.16.85.1/30 

set interfaces ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64 

set interfaces ge-1/0/6 unit 0 family mpls 

set interfaces xe-1/3/0 unit 0 family inet address 172.16.90.1/30 

set interfaces xe-1/3/0 unit 0 family inet6 address 2001:db8:90:1:1::1/64 

set interfaces xe-1/3/0 unit 0 family mpls 

set interfaces loO unit O family inet address 172.16.3.3/32 primary 

set interfaces loO unit O family inet6 address 2001:db8::3:3:3:3/128 primary 

set interfaces loO unit O family mpls 

set routing-options srlg srlg1 srlg-value 1001 

set routing-options srlg srlg2 srlg-value 1002 

set routing-options srlg srlg3 srlg-value 1003 

set routing-options srlg srlg4 srlg-value 1004 

set routing-options srlg srlg5 srlg-value 1005 

set routing-options srlg srlg6 srlg-value 1006 

set routing-options srlg srlg7 srlg-value 1007 

set routing-options srlg srlg8 srlg-value 1008 

set routing-options srlg srlg9 srlg-value 1009 

set routing-options srlg srlg10 srlg-value 10010 

set routing-options srlg srlg11 srlg-value 10011 

set routing-options srlg srlg12 srlg-value 10012 

set routing-options router-id 172.16.3.3 

set routing-options forwarding-table export ecmp 

set routing-options backup-selection destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group 
include-all c2 

set routing-options backup-selection destination 10.1.1.0/30 interface all admin-group exclude c3 

set routing-options backup-selection destination 10.1.1.0/30 interface all srlg strict 

set routing-options backup-selection destination 10.1.1.0/30 interface all protection-type node 

set routing-options backup-selection destination 10.1.1.0/30 interface all 
bandwidth-greater-equal-primary 

set routing-options backup-selection destination 10.1.1.0/30 interface all neighbor preference 
172.16.7.7 

set routing-options backup-selection destination 10.1.1.0/30 interface all root-metric lowest 

set routing-options backup-selection destination 10.1.1.0/30 interface all metric-order root 

set routing-options backup-selection destination 172.16.30.0/30 interface all admin-group exclude 
c5 

set routing-options backup-selection destination 172.16.30.0/30 interface all srlg strict 

set routing-options backup-selection destination 172.16.30.0/30 interface all protection-type node 

set routing-options backup-selection destination 172.16.30.0/30 interface all 
bandwidth-greater-equal-primary 
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set routing-options backup-selection destination 172.16.30.0/30 interface all neighbor preference 
172.16.7.7 

set routing-options backup-selection destination 172.16.30.0/30 interface all root-metric lowest 

set routing-options backup-selection destination 172.16.30.0/30 interface all metric-order root 

set routing-options backup-selection destination 172.16.45.0/30 interface all admin-group exclude 
c5 

set routing-options backup-selection destination 172.16.45.0/30 interface all srlg strict 

set routing-options backup-selection destination 172.16.45.0/30 interface all protection-type node 

set routing-options backup-selection destination 172.16.45.0/30 interface all 
bandwidth-greater-equal-primary 

set routing-options backup-selection destination 172.16.45.0/30 interface all neighbor preference 
172.16.7.7 

set routing-options backup-selection destination 172.16.45.0/30 interface all root-metric lowest 

set routing-options backup-selection destination 172.16.45.1/30 interface all metric-order root 

set protocols rsvp interface all 

set protocols mpls admin-groups cO 0 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 
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set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols mpls interface ge-0/0/5.0 admin-group cO 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 link-protection 
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 10 

set protocols ospf area 0.0.0.0 interface xe-0/3/1.0 metric 21 

set protocols ospf area 0.0.0.0 interface ge-1/0/0.0 metric 13 

set protocols ospf area 0.0.0.0 interface ge-1/0/6.0 metric 15 

set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 link-protection 
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 22 

set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 link-protection 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 10 

set protocols ospf3 area 0.0.0.0 interface xe-0/3/1.0 metric 21 

set protocols ospf3 area 0.0.0.0 interface ge-1/0/0.0 metric 13 

set protocols ospf3 area 0.0.0.0 interface ge-1/0/6.0 metric 15 

set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 link-protection 
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 22 

set policy-options policy-statement ecmp term 1 then load-balance per-packet 


set routing-options srlg srlg1 srlg-value 1001 
set routing-options srlg srlg2 srlg-value 1002 
set routing-options srlg srlg3 srlg-value 1003 
set routing-options srlg srlg4 srlg-value 1004 
set routing-options srlg srlg5 srlg-value 1005 
set routing-options srlg srlg6 srlg-value 1006 
set routing-options srlg srlg7 srlg-value 1007 
set routing-options srlg srlg8 srlg-value 1008 
set routing-options srlg srlg9 srlg-value 1009 
set routing-options srlg srlg10 srig-value 10010 
set routing-options srlg srlg11 srlg-value 10011 
set routing-options srlg srlg12 srlg-value 10012 
set routing-options router-id 172.16.4.4 

set protocols rsvp interface all 

set protocols mpls admin-groups cO O 


set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 18 
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-1/1/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface xe-0/3/1.0 metric 21 
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 18 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10 
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set protocols ospf3 area 0.0.0.0 interface ge-1/1/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-0/3/1.0 metric 21 


set routing-options srlg srlg1 srlg-value 1001 
set routing-options srlg srlg2 srlg-value 1002 
set routing-options srlg srlg3 srlg-value 1003 
set routing-options srlg srlg4 srlg-value 1004 
set routing-options srlg srlg5 srlg-value 1005 
set routing-options srlg srlg6 srlg-value 1006 
set routing-options srlg srlg7 srlg-value 1007 
set routing-options srlg srlg8 srlg-value 1008 
set routing-options srlg srlg9 srlg-value 1009 
set routing-options srlg srlg10 srlg-value 10010 
set routing-options srlg srlg11 srlg-value 10011 
set routing-options srlg srilg12 srlg-value 10012 
set routing-options router-id 172.16.5.5 

set protocols rsvp interface all 

set protocols mpls admin-groups cO 0 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 
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set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 51 
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 13 
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 51 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/1.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 13 
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 10 


set routing-options srlg srlg1 srlg-value 1001 
set routing-options srlg srlg2 srlg-value 1002 
set routing-options srlg srlg3 srlg-value 1003 
set routing-options srlg srlg4 srlg-value 1004 
set routing-options srlg srlg5 srlg-value 1005 
set routing-options srlg srlg6 srlg-value 1006 
set routing-options srlg srlg7 srlg-value 1007 
set routing-options srlg srlg8 srlg-value 1008 
set routing-options srlg srlg9 srlg-value 1009 
set routing-options srlg srlg10 srig-value 10010 
set routing-options srlg srlg11 srlg-value 10011 
set routing-options srlg srlg12 srlg-value 10012 
set routing-options router-id 172.16.6.6 

set protocols rsvp interface all 

set protocols mpls admin-groups cO O 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 
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set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 25 

set protocols mpls admin-groups c26 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 

set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 52 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 12 
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 metric 15 
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 52 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 12 
set protocols ospf3 area 0.0.0.0 interface ge-0/0/4.0 metric 15 
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10 
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set routing-options srlg srlg1 srlg-value 1001 
set routing-options srlg srlg2 srlg-value 1002 
set routing-options srlg srlg3 srlg-value 1003 
set routing-options srlg srlg4 srlg-value 1004 
set routing-options srlg srlg5 srlg-value 1005 
set routing-options srlg srlg6 srlg-value 1006 
set routing-options srlg srlg7 srlg-value 1007 
set routing-options srlg srlg8 srlg-value 1008 
set routing-options srlg srlg9 srlg-value 1009 
set routing-options srlg srlg10 srlg-value 10010 
set routing-options srlg srlg11 srlg-value 10011 
set routing-options srlg srlg12 srlg-value 10012 
set routing-options router-id 172.16.7.7 

set protocols rsvp interface all 

set protocols mpls admin-groups cO 0 

set protocols mpls admin-groups c1 1 

set protocols mpls admin-groups c2 2 

set protocols mpls admin-groups c3 3 

set protocols mpls admin-groups c4 4 

set protocols mpls admin-groups c5 5 

set protocols mpls admin-groups c6 6 

set protocols mpls admin-groups c7 7 

set protocols mpls admin-groups c8 8 

set protocols mpls admin-groups c9 9 

set protocols mpls admin-groups c10 10 

set protocols mpls admin-groups c11 11 

set protocols mpls admin-groups c12 12 

set protocols mpls admin-groups c13 13 

set protocols mpls admin-groups c14 14 

set protocols mpls admin-groups c15 15 

set protocols mpls admin-groups c16 16 

set protocols mpls admin-groups c17 17 

set protocols mpls admin-groups c18 18 

set protocols mpls admin-groups c19 19 

set protocols mpls admin-groups c20 20 

set protocols mpls admin-groups c21 21 

set protocols mpls admin-groups c22 22 

set protocols mpls admin-groups c23 23 

set protocols mpls admin-groups c24 24 

set protocols mpls admin-groups c25 26 

set protocols mpls admin-groups c27 27 

set protocols mpls admin-groups c28 28 
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set protocols mpls admin-groups c29 29 

set protocols mpls admin-groups c30 30 

set protocols mpls admin-groups c31 31 

set protocols mpls interface all 

set protocols mpls interface xe-0/3/0.0 srlg srlg8 

set protocols ospf area 0.0.0.0 interface ge-0/1/5.0 metric 23 
set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 10 
set protocols ospf area 0.0.0.0 interface ge-1/0/0.0 metric 13 
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 22 
set protocols ospf area 0.0.0.0 interface xe-1/2/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-0/1/5.0 metric 23 
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 10 
set protocols ospf3 area 0.0.0.0 interface ge-1/0/0.0 metric 13 
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 22 
set protocols ospf3 area 0.0.0.0 interface xe-1/2/0.0 metric 10 


Configuring Device R3 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R3: 


1. Configure the interfaces. 


[edit interfaces] 

user@R3# set ge-0/0/5 unit O family inet address 172.16.50.2/30 
user@R3# set ge-0/0/5 unit O family inet6 address 2001:db8:50:1:1::2/64 
user@R3# set ge-0/0/5 unit 0 family mpls 


user@R3# set xe-0/3/1 unit O family inet address 172.16.75.1/30 
user@R3# set xe-0/3/1 unit O family inet6 address 2001:db8:75:1:1::1/64 
user@R3# set xe-0/3/1 unit 0 family mpls 


user@R3# set ge-1/0/0 unit 0 family inet address 172.16.80.1/30 
user@R3# set ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64 
user@R3# set ge-1/0/0 unit O family mpls 


user@R3# set ge-1/0/5 unit O family inet address 172.16.200.1/24 
user@R3# set ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64 
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user@R3# set ge-1/0/6 unit O family inet address 172.16.85.1/30 
user@R3# set ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64 
user@R3# set ge-1/0/6 unit 0 family mpls 


user@R3# set xe-1/3/0 unit O family inet address 172.16.90.1/30 
user@R3# set xe-1/3/0 unit O family inet6 address 2001:db8:90:1:1::1/64 
user@R3# set xe-1/3/0 unit 0 family mpls 


user@R3# set loO unit 0 family inet address 172.16.3.3/32 primary 
user@R3# set loO unit O family inet6 address 2001:db8::3:3:3:3/128 primary 
user@R3# set loO unit 0 family mpls 


2. Configure srlg values. 


[edit routing-options] 

user@R3# set srlg srlg1 srlg-value 1001 
user@R3# set srlg srlg2 srlg-value 1002 
user@R3# set srlg srlg3 srlg-value 1003 
user@R3# set srlg srlg4 srlg-value 1004 
user@R3# set srlg srlg5 srig-value 1005 
user@R3# set srlg srlg6 srlg-value 1006 
user@R3# set srlg srlg7 srlg-value 1007 
user@R3# set srlg srlg8 srlg-value 1008 
user@R3# set srlg srlg9 srlg-value 1009 
user@R3# set srlg srlg10 srlg-value 10010 
user@R3# set srlg srlg11 srlg-value 10011 
user@R3# set srlg srlg12 srlg-value 10012 


3. Configure the ID of the router. 


[edit routing-options] 
user@R3# set router-id 172.16.3.3 


4. Apply the routing policy to all equal-cost multipaths exported from the routing table to the forwarding 
table. 


[edit routing-options] 
user@R3# set forwarding-table export ecmp 


5. Configure attributes of the backup selection policy. 
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[edit routing-options backup-selection] 

user@R3# set destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group include-all c2 
user@R3# set destination 10.1.1.0/30 interface all admin-group exclude c3 

user@R3# set destination 10.1.1.0/30 interface all srlg strict 

user@R3# set destination 10.1.1.0/30 interface all protection-type node 

user@R3# set destination 10.1.1.0/30 interface all bandwidth-greater-equal-primary 
user@R3# set destination 10.1.1.0/30 interface all neighbor preference 172.16.7.7 
user@R3# set destination 10.1.1.0/30 interface all root-metric lowest 

user@R3# set destination 10.1.1.0/30 interface all metric-order root 


user@R3# set destination 172.16.30.0/30 interface all admin-group exclude c5 
user@R3# set destination 172.16.30.0/30 interface all srlg strict 

user@R3# set destination 172.16.30.0/30 interface all protection-type node 

user@R3# set destination 172.16.30.0/30 interface all bandwidth-greater-equal-primary 
user@R3# set destination 172.16.30.0/30 interface all neighbor preference 172.16.7.7 
user@R3# set destination 172.16.30.0/30 interface all root-metric lowest 

user@R3# set destination 172.16.30.0/30 interface all metric-order root 


user@R3# set destination 192.168.45.0/30 interface all admin-group exclude c5 
user@R3# set destination 192.168.45.0/30 interface all srlg strict 

user@R3# set destination 192.168.45.0/30 interface all protection-type node 

user@R3# set destination 192.168.45.0/30 interface all bandwidth-greater-equal-primary 
user@R3# set destination 192.168.45.0/30 interface all neighbor preference 172.16.7.7 
user@R3# set destination 192.168.45.0/30 interface all root-metric lowest 

user@R3# set destination 192.168.45.0/30 interface all metric-order root 


6. Enable RSVP on all the interfaces. 


[edit protocols] 
user@R3# set rsvp interface all 


7. Configure administrative groups. 


[edit protocols mpls] 

user@R3# set admin-groups cO 0 
user@R3# set admin-groups ci 1 
user@R3# set admin-groups c2 2 
user@R3# set admin-groups c3 3 
user@R3# set admin-groups c4 4 
user@R3# set admin-groups c5 5 
user@R3# set admin-groups c6 6 
user@R3# set admin-groups c7 7 


473 


user@R3# set admin-groups c8 8 

user@R3# set admin-groups c9 9 

user@R3# set admin-groups c10 10 
user@R3# set admin-groups c1i1 11 
user@R3# set admin-groups c12 12 
user@R3# set admin-groups c13 13 
user@R3# set admin-groups c14 14 
user@R3# set admin-groups c15 15 
user@R3# set admin-groups c16 16 
user@R3# set admin-groups c17 17 
user@R3# set admin-groups c18 18 
user@R3# set admin-groups c19 19 
user@R3# set admin-groups c20 20 
user@R3# set admin-groups c21 21 
user@R3# set admin-groups c22 22 
user@R3# set admin-groups c23 23 
user@R3# set admin-groups c24 24 
user@R3# set admin-groups c25 25 
user@R3# set admin-groups c26 26 
user@R3# set admin-groups c27 27 
user@R3# set admin-groups c28 28 
user@R3# set admin-groups c29 29 
user@R3# set admin-groups c30 30 
user@R3# set admin-groups c31 31 


8. Enable MPLS on all the interfaces and configure administrative group for an interface. 


[edit protocols mpls] 
user@R3# set interface all 
user@R3# set interface ge-0/0/5.0 admin-group cO 


9. Enable link protection and configure metric values on all the interfaces for an OSPF area. 


[edit protocols ospf] 

user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protection 
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10 
user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21 
user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13 
user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15 
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection 
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22 


10. Enable link protection and configure metric values on all the interfaces for an OSPF3 area. 


[edit protocols ospf3] 

user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protection 
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10 
user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21 
user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13 
user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15 
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection 
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22 


11. Configure the routing policy. 


[edit policy-options] 
user@R3# set policy-statement ecmp term 1 then load-balance per-packet 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R3# show interfaces 
ge-0/0/5 { 
unit O { 
family inet { 
address 192.168.50.2/30; 
} 
family ineté { 
address 2001:db8:50:1:1::2/64; 
} 


family mpls; 


} 
xe-0/3/1 { 
unit O { 
family inet { 
address 192.168.75.1/30; 
} 
family ineté { 
address 2001:db8:75:1:1::1/64; 
} 


family mpls; 
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} 
ge-1/0/0 { 
unit O { 
family inet { 
address 192.168.80.1/30; 
} 
family ineté { 
address 2001:db8:80:1:1::1/64; 
} 


family mpls; 


} 
ge-1/0/5 { 
unit O { 
family inet { 
address 172.16.200.1/24; 
} 
family ineté { 
address 2001:db8:200:1:1::1/64; 


} 
ge-1/0/6 { 
unit O { 
family inet { 
address 192.168.85.1/30; 
} 
family ineté { 
address 2001:db8:85:1:1::1/64; 
} 


family mpls; 


} 
xe-1/3/0 { 
unit O { 
family inet { 
address 192.168.90.1/30; 
} 
family ineté { 
address 2001:db8:90:1:1::1/64; 
} 


family mpls; 
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} 
loO { 
unit O { 
family inet { 
address 172.16.3.3/32 { 
primary; 


} 
family ineté { 
address 2001:db8:3:3:3:3/128 { 
primary; 


} 


family mpls; 


user@R3# show protocols 
rsvp { 
interface all; 
} 
mpls { 
admin-groups { 
cO O; 
c11; 
C2 2 
c3 3; 
c4 4; 
c5 5; 
c6 6; 
c7 7; 
c8 8; 
EY & 
c10 10; 
c11 11; 
c12 12; 
c13 13; 
c14 14; 
c15 15; 
c16 16; 
eil/ a7 
c18 18; 
c19 19; 
c20 20; 
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Pil Bile 
c22 22; 
C23 23; 
c24 24; 
C2525; 
C26 26; 
C27 27; 
c28 28; 
C29: 
c30 30; 
coneod 
} 
interface all; 
interface ge-0/0/5.0 { 
admin-group cO; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/5.0 { 
link-protection; 
metric 10; 
} 
interface xe-0/3/1.0 { 
metric 21; 
} 
interface ge-1/0/0.0 { 
metric 13; 
} 
interface ge-1/0/6.0 { 
metric 15; 
} 
interface xe-1/3/0.0 { 
link-protection; 
metric 22; 


} 
ospf3 { 
area 0.0.0.0 { 
interface ge-0/0/5.0 { 
link-protection; 
metric 10; 


interface xe-0/3/1.0 { 
metric 21; 

} 

interface ge-1/0/0.0 { 
metric 13; 

} 

interface ge-1/0/6.0 { 
metric 15; 

} 

interface xe-1/3/0.0 { 
link-protection; 
metric 22; 


user@R3# show routing-options 
srig { 


} 


srlg1 srig-value 1001; 
srlg2 srlg-value 1002; 
srlg3 srlg-value 1003; 
srlg4 srig-value 1004; 
srlg5 srig-value 1005; 
srlg6 srig-value 1006; 
srlg7 srlg-value 1007; 
srlg8 srlg-value 1008; 
srlg9 srlg-value 1009; 
srlg10 srlg-value 10010; 
srlgi1 srig-value 10011; 
srlg12 srig-value 10012; 


router-id 172.16.3.3; 
forwarding-table { 


} 


export ecmp; 


backup-selection { 


destination 10.1.1.0/30 { 
interface xe-1/3/0.0 { 
admin-group { 
include-all c2; 


} 
interface all { 
admin-group { 
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exclude c3; 
} 
srlg strict; 
protection-type node; 
bandwidth-greater-equal-primary; 
node { 
preference 172.16.7.7; 
} 
root-metric lowest; 
metric-order root; 


} 
destination 172.16.30.0/30 { 
interface all { 
admin-group { 
exclude c5; 
} 
srlg strict; 
protection-type node; 
bandwidth-greater-equal-primary; 
node { 
preference 172.16.7.7; 
} 
root-metric lowest; 
metric-order root; 


} 
destination 192.168.45.0/30 { 
interface all { 
admin-group { 
exclude c5; 
} 
srlg strict; 
protection-type node; 
bandwidth-greater-equal-primary; 
node { 
preference 172.16.7.7; 
} 
root-metric lowest; 
metric-order root; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Verifying the Routes | 480 
Verifying the OSPF Route | 484 
Verifying the OSPF3 Route | 484 


Verifying the Backup Selection Policy for Device R3 | 485 


Confirm that the configuration is working properly. 


Verifying the Routes 


Purpose 


Verify that the expected routes are learned. 
Action 
From operational mode, run the show route command for the routing table. 


user@R3> show route 


inet.0: 48 destinations, 48 routes (48 active, 0 holddown, O hidden) 




















+ = Active Route, Last Active, * = Both 
WW 5G 6 8B 5 3 SZ es (Dalia /0) |) OAS22e27) 

> wile lod. 0 
10.4.0.0/16 “(StactLe/S]| W2s22257 

> ito 10,92.391,254 wila txg0.0 
MORES Oke OY AKG x(Siraicie/ S|] O2822357 

> tO 10.92.31,254 wia Esqo0.€ 
106,128 0/17 “(Sireicie/S]| O282238 57 

> tO 10,.92.31,.254 wie txgo0.0 
10.9.0 .0/16 “([SitatiLe/S]| O2322257 

> tO 10,92.31,254 wie txgo0.0 
NORE EOR OR OY/elk6 al Sitecttepinc onl mm OP non 

> tO 10,92. 31.254 wie tsqo0.0 
IO, 13,4, 0/28 w(Straicie/S]| O2822357 

> ito 10,92.91,254 wila txg0.0 
10.1310 .,0/23 a(StacLe/S]| W2s22257 

> tO 10,92.31,254 wia txgo0.0 
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> tO 10.92.31. 
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> tO 10,9265. 
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10,216.00 .0/16 “[StatiLe/S]| 2322257 

> tO 10,.92.31.,254 wia tsqo0.0 
ID ZU ,13 ,0/ 24 w([Statie/S]| 02822357 

> to 10,.92.31,254 wie tsqo0.0 
NO 23 14, 0/24 “(StatLe/S]| W2s22257 

Sito 10,92.391,254 wia exo. 0 
10.218 ,16 0/20 a([StactLe/S]| W2s22257 

> tO 10.92.31,254 wie tsqo0.€ 
10 23.32 .0/ 20 x(Siraicie/ S|] O2822357 

> tO 10.92.31,254 wia Esqo0. 0 
10.227 -0.0/16 “[SitatiLe/S]| 2922257 

> to 10,92.3i1,254 wie Exg0.0 
172.1650 .0/ 30 = Dalwscie/ Ol) O2219s55 

> via ge-0/0/5.0 
172.116.5027 32 “hocal/O] O26i19s 58 

Local via ge-0/0/5.0 

VIZ 16575 .0/ 30 = (Dalmacic/O]] O28193 55) 

2 Wile. e—0)/ 31/1 0 
172.16, 75,1732 Shoeeil/Oi]] O2219¢57 








Local via xe-0/3/1.0 
172 M6 24 195/32 = [DaLweace/O]| O2322657 


> via 100.0 


172 -16.0.0/12 ~(SicaeLe/ 5S] 02322857) 
> to 10,92.31,254 wie txgo0.0 
1925168.0.0/16 ~(SicaicLe/ 5S] O2322 857) 


> tO 10,92.31.,254 wile tsqo0.0 
192. 16S 102 .0/23 w([Staitie/S]| O2822357 

> tO 10,92.31,254 wie tsqo0.0 
192 168,136, 0/ 24 e[Stacle/S] W2e22s57 

> ito 10,.92.31,254 wia txgo0.0 
192 168 136,192/32 “[Sttacie/S] O2s22357 

> tO 10.,.92.31,254 wie tsgo0.€ 


























1/2, 168,137 0/24 Pal Sitecltesker/sonl OZ OW) 
> tO 10.92.31,254 wia Esqo0.0 
192.168.2353 .5/ 32 “(CSPr/10]] OOslesss, meitrrie 
ultiRecv 


iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0O hidden) 








+ = Active Route, Last Active, * = Both 


AT  OOOS . BOs .ALGOO, OOOO 10S, OO01 . 1280. 9202 . 4195/1152 
= |(Darecr/ Ol] WO2322 857 


> via 100.0 
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mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 

















+ = Active Route, Last Active, * = Both 

0 AME TeSyA0) OOS 5) mamcierete mls 
Receive 

il *(MPLS/O] 00:16:55, metric 1 
Receive 

2 (MES /O)i| OOS WGsSS, imsiereale: Ih 
Receive 

ALS} “(MES/ Oi] OOS IGSS5,, imsereake Ih 

















Receive 


inet6.0: 10 destinations, 11 routes (10 active, 0 holddown, 0O hidden) 


+ = 


Oe: 


ZOO: 


AO On ss 


ZOOL s 


2001: 


AOOIs: 


fe8s0: 


fe80: 


fe80: 


fes0: 


Active Route, - = Last Active, * = Both 
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Local via ge-0/0/5.0 
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> Wie 3-0/3 /1.0 
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27 |[Ikyeyeeull /0)]) (02e 1L's)e Sys) 
Local via ge-0/0/5.0 
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2 | eee / Oj] O2Ze193 57 
Local via xe-0/3/1.0 
BBS SABO 9S ieioul B Sica B/ L213) 
=< |DaLeace/O]] O23 22857 


= wile od, 0 














Meaning 


The output shows all Device R3 routes. 
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Verifying the OSPF Route 


Purpose 
Verify the routing table of OSPF. 


Action 


From operational mode, run the show ospf route detail command for Device R3. 


user@R3> show ospf route detail 


Topology default Route Table: 


Prefix Path Route NH Metric NextHop Nexthop 
Type Type Type Interface Address/LSP 
172,16, 50.0/3€ Intra Network IP 10 ge-0/0/5.0 


ace O.0.0.0, orieim 172 16.3.3, Dredority low 
17216, 75.0/ 30 Intra Network IP 2 se-0/ 3/1. 0 
axeee 0.0.0.0, orieam 172 16.5.3, predority llow 


Meaning 


The output displays the routing table of OSPF routers. 


Verifying the OSPF3 Route 


Purpose 
Verify the routing table of OSPF3. 


Action 
From operational mode, run the show ospf3 route detail command for Device R3. 


user@R3> show ospf3 route detail 


Prefix Path Route NH Metric 
iype Type Lyoe 
AOOL sclisiss SOs i eile 3/154 Intra Network IP 10 





NH-interface ge-0/0/5.0 
Area 0.0.0.0, Origin 172.16.3.3, Prkoriity ihe 
200Lgcloss7 Sg isiles/S4 Intra Network sla Bll 
NH-interface xe-0/3/1.0 
Meee O.0.0.0, Olean LVZ016.3 43, Pieioruty ilow 





Meaning 
The output displays the routing table of OSPF3 routers. 


Verifying the Backup Selection Policy for Device R3 


Purpose 
Verify the backup selection policy for Device R3. 


Action 
From operational mode, run the show backup-selection command for Device R3. 


user@R3> show backup-selection 


Pieces: 10 ,1.1.0/30 


Interface: all 





Admin-group exclude: c3 
Neighbor preference: 172.16.7.7 
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= 





Primary: Enabled, Root-metric: lowest, Dest-metric: lowest 





etric Evaluation Order: Root-metric, Dest-metric 








Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric 


Interface: xe-1/3/0.0 
Admin-group include-all: c2 
Protection Type: Link, Downstream Paths Only: Disabled, SRLG: Loose, B/w >= 
Primary: Disabled, Root-metric: lowest, Dest-metric: lowest 


Metric Evaluation Order: Dest-metric, Root-metric 





Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric 
Pireurise9 172, 16, 30,0/30 


Interface: all 








Admin-group exclude: c5 
Neighbor preference: 172.16.7.7 
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= 





Primary: Enabled, Root-metric: lowest, Dest-metric: lowest 





etric Evaluation Order: Root-metric, Dest-metric 





Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric 





Pieces: 172,16,.45.0/ 30 


Interface: all 





Admin-group exclude: c5 
Neighbor preference: 172.16.7.7 
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= 


Primary: Enabled, Root-metric: lowest, Dest-metric: lowest 








etric Evaluation Order: Root-metric, Dest-metric 
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Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric 





Meaning 
The output displays the configured policies per prefix per primary next-hop interface. 


SEE ALSO 


| backup-selection (Protocols ISIS) 


| Example: Injecting OSPF Routes into the BGP Routing Table 


IN THIS SECTION 


Requirements | 486 
Overview | 487 
Configuration | 487 
Verification | 490 


Troubleshooting | 490 


This example shows how to create a policy that injects OSPF routes into the BGP routing table. 


Requirements 


Before you begin: 
e Configure network interfaces. 
e Configure external peer sessions. See Example: Configuring External BGP Point-to-Point Peer Sessions. 


e Configure interior gateway protocol (IGP) sessions between peers. 
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Overview 


In this example, you create a routing policy called injectpolicy1 and a routing term called injectterm1. The 
policy injects OSPF routes into the BGP routing table. 


Configuration 


IN THIS SECTION 


@ Configuring the Routing Policy | 487 


@ Configuring Tracing for the Routing Policy | 489 


Configuring the Routing Policy 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf 
set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 
set policy-options policy-statement injectpolicy1 term injectterm1 then accept 

set protocols bgp export injectpolicy1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To inject OSPF routes into a BGP routing table: 


1. Create the policy term. 


[edit policy-options policy-statement injectpolicy1] 
user@host# set term injectterm1 


2. Specify OSPF as a match condition. 


[edit policy-options policy-statement injectpolicy1 term injectterm1] 
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user@host# set from protocol ospf 


3. Specify the routes from an OSPF area as a match condition. 


[edit policy-options policy-statement injectpolicy1 term injectterm1] 
user@host# set from area 0.0.0.1 


4. Specify that the route is to be accepted if the previous conditions are matched. 


[edit policy-options policy-statement injectpolicy1 term injectterm1] 
user@host# set then accept 


5. Apply the routing policy to BGP. 


[edit] 
user@host# set protocols bgp export injectpolicy1 


Results 


Confirm your configuration by entering the show policy-options and show protocols bgp commands from 
configuration mode. If the output does not display the intended configuration, repeat the instructions in 
this example to correct the configuration. 


user@host# show policy-options 
policy-statement injectpolicy1 { 
term injectterm1 { 
from { 
protocol ospf; 
area 0.0.0.1; 
} 


then accept; 


user@host# show protocols bgp 


export injectpolicy1; 


If you are done configuring the device, enter commit from configuration mode. 
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Configuring Tracing for the Routing Policy 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


set policy-options policy-statement injectpolicy1 term injectterm1 then trace 
set routing-options traceoptions file ospf-bgp-policy-log 

set routing-options traceoptions file size 5m 

set routing-options traceoptions file files 5 

set routing-options traceoptions flag policy 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


1. Include a trace action in the policy. 


[edit policy-options policy-statement injectpolicy1 term injectterm1] 
user@host# then trace 


2. Configure the tracing file for the output. 


[edit routing-options traceoptions] 
user@host# set file ospf-bgp-policy-log 
user@host# set file size 5m 
user@host# set file files 5 

user@host# set flag policy 


Results 

Confirm your configuration by entering the show policy-options and show routing-options commands 
from configuration mode. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 


user@host# show policy-options 
policy-statement injectpolicy1 { 
term injectterm1 { 
then { 
trace; 


user@host# show routing-options 
traceoptions { 
file ospf-bgp-policy-log size 5m files 5; 
flag policy; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


Confirm that the configuration is working properly. 


Verifying That the Expected BGP Routes Are Present 


Purpose 


Verify the effect of the export policy. 
Action 


From operational mode, enter the show route command. 


Troubleshooting 


IN THIS SECTION 


@ —_Using the show log Command to Examine the Actions of the Routing Policy | 490 


Using the show log Command to Examine the Actions of the Routing Policy 


Problem 


The routing table contains unexpected routes, or routes are missing from the routing table. 


Solution 

If you configure policy tracing as shown in this example, you can run the show log ospf-bgp-policy-log 
command to diagnose problems with the routing policy. The show log ospf-bgp-policy-log command 
displays information about the routes that the injectpolicy1 policy term analyzes and acts upon. 
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| Example: Redistributing Static Routes into OSPF 


IN THIS SECTION 


Requirements | 491 
Overview | 491 
Configuration | 491 


Verification | 493 


This example shows how to create a policy that redistributes static routes into OSPF. 


Requirements 


Before you begin: 


e Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


Overview 


In this example, you create a routing policy called exportstatic1 and a routing term called exportstatic1. 
The policy injects static routes into OSPF. This example includes the following settings: 


policy-statement—Defines the routing policy. You specify the name of the policy and further define the 


elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens 
(- ) and be up to 255 characters long. 


term—Defines the match condition and applicable actions for the routing policy. The term name can 
contain letters, numbers, and hyphens ( - ) and be up to 255 characters long. You specify the name of 
the term and define the criteria that an incoming route must match by including the from statement and 
the action to take if the route matches the conditions by including the then statement. In this example 


you specify the static protocol match condition and the accept action. 


export—Applies the export policy you created to be evaluated when routes are being exported from the 
routing table into OSPF. 


Configuration 


CLI Quick Configuration 
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To quickly create a policy that injects static routes into OSPF, copy the following commands and paste 
them into the CLI. 


[edit] 

set policy-options policy-statement exportstatic1 term exportstatic1 from protocol static 
set policy-options policy-statement exportstatic1 term exportstatic1 then accept 

set protocols ospf export exportstatic1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide. 


To inject static routes into OSPF: 


1. Create the routing policy. 


[edit] 
user@host# edit policy-options policy-statement exportstatic1 


2. Create the policy term. 


[edit policy-options policy-statement exportstatic1] 
user@host# set term exportstatic1 


oO 


. Specify static as a match condition. 


[edit policy-options policy-statement exportstatic1 term exportstatic1] 
user@host# set from protocol static 


4. Specify that the route is to be accepted if the previous condition is matched. 


[edit policy-options policy-statement exportstatic1 term exportstatic1] 
user@host# set then accept 


5. Apply the routing policy to OSPF. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 
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[edit] 
user@host# set protocols ospf export exportstatic1 


6. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 

Confirm your configuration by entering the show policy-options and show protocols ospf commands. If 
the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show policy-options 
policy-statement exportstatic1 { 
term exportstatic1 { 
from protocol static; 
then accept; 


user@host# show protocols ospf 


export exportstatic1; 


To confirm your OSPFv3 configuration, enter the show policy-options and the show protocols ospf3 
commands. 


Verification 


IN THIS SECTION 


@ Verifying That the Expected Static Routes Are Present | 494 
@ Verifying That AS External LSAs Are Added to the Routing Table | 494 


Confirm that the configuration is working properly. 
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Verifying That the Expected Static Routes Are Present 


Purpose 


Verify the effect of the export policy. 
Action 
From operational mode, enter the show route command. 


Verifying That AS External LSAs Are Added to the Routing Table 


Purpose 
On the routing device where you configured the export policy, verify that the routing device originates 
an AS external LSA for the static routes that are added to the routing table. 


Action 
From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3 
database command for OSPFv3. 


Example: Configuring an OSPF Import Policy 


IN THIS SECTION 


Requirements | 494 
Overview | 495 
Configuration | 495 


Verification | 499 


This example shows how to create an OSPF import policy. OSPF import policies apply to external routes 
only. An external route is a route that is outside the OSPF autonomous system (AS). 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71. 
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e Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Overview 


External routes are learned by AS boundary routers. External routes can be advertised throughout the 
OSPF domain if you configure the AS boundary router to redistribute the route into OSPF. An external 
route might be learned by the AS boundary router from a routing protocol other than OSPF, or the external 
route might be a static route that you configure on the AS boundary router. 


For OSPF v3, the link-state advertisement (LSA) is referred to as the interarea prefix LSA and performs the 
same function as a network-summary LSA performs for OSPFv2. An area border router (ABR) originates 
an interarea prefix LSA for each IPvé6 prefix that must be advertised into an area. 


OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF 
neighbors. The import policy does not impact the OSPF database. This means that the import policy has 
no impact on the link-state advertisements. The filtering is done only on external routes in OSPF. The 
intra-area and interarea routes are not considered for filtering. The default action is to accept the route 
when the route does not match the policy. 


This example includes the following OSPF policy settings: 


e policy-statement—Defines the routing policy. You specify the name of the policy and further define the 
elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens 
(- ) and be up to 255 characters long. 


e export—Applies the export policy you created to be evaluated when network summary LSAs are flooded 
into an area. In this example, the export policy is named export_static. 


e import—Applies the import policy you created to prevent external routes from being added to the routing 
table. In this example, the import policy is named filter_routes. 


The devices you configure in this example represent the following functions: 


e R1—Device R1 is in area 0.0.0.0 and has a direct connection to device R2. R1 has an OSPF export policy 
configured. The export policy redistributes static routes from R1’s routing table into R1’s OSPF database. 
Because the static route is in R1’s OSPF database, the route is advertised in an LSA to R1’s OSPF neighbor. 
R1’s OSPF neighbor is device R2. 


e R2—Device R2 is in area 0.0.0.0 and has a direct connection to device R1. R2 has an OSPF import policy 
configured that matches the static route to the 10.0.16.0/30 network and prevents the static route from 
being installed in R2’s routing table. R2’s OSPF neighbor is device R1. 


Configuration 


CLI Quick Configuration 
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To quickly configure an OSPF import policy, paste them into a text file, remove any line breaks, change 
any details necessary to match your network configuration, copy and paste the commands into the CLI at 
the [edit] hierarchy level, and then enter commit from configuration mode. 


Configuration on Device R1: 


[edit] 

set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30 

set protocols ospf export export_static 

set protocols ospf area 0.0.0.0 interface so-0/2/0 

set policy-options policy-statement export_static from protocol static 
set policy-options policy-statement export_static then accept 


Configuration on Device R2: 


[edit] 

set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30 

set protocols ospf import filter_routes 

set protocols ospf area 0.0.0.0 interface so-0/2/0 

set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact 
set policy-options policy-statement filter_routes then reject 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide. 


To configure an OSPF import policy: 


1. Configure the interfaces. 


[edit] 
user@R1# set interfaces so-0/2/0 unit O family inet address 10.0.2.1/30 


[edit] 
user@R2# set interfaces so-0/2/0 unit O family inet address 10.0.2.2/30 


2. Enable OSPF on the interfaces. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


3. 


[edit] 
user@R1# set protocols ospf area 0.0.0.0 interface so-0/2/0 


[edit] 
user@R2# set protocols ospf area 0.0.0.0 interface so-0/2/0 


On R1, redistribute the static route into OSPF. 


[edit] 

user@R1# set protocols ospf export export_static 

user@R1# set policy-options policy-statement export_static from protocol static 
user@R1# set policy-options policy-statement export_static then accept 


4. On R2, configure the OSPF import policy. 


[edit] 

user@R2# set protocols ospf import filter_routes 

user@R2# set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exact 
user@R2# set policy-options policy-statement filter_routes then reject 


5. If you are done configuring the devices, commit the configuration. 
[edit] 
user@host# commit 

Results 


Confirm your configuration by entering the show interfaces, show policy-options, and show protocols 


ospf commands on the appropriate device. If the output does not display the intended configuration, 


repeat the instructions in this example to correct the configuration. 


Output for R11: 


user@R1# show interfaces 
so-0/2/0 { 


unit O { 
family inet { 
address 10.0.2.1/30; 
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user@R1# show policy-options 
policy-statement export_static { 
from protocol static; 
then accept; 


user@R1# show protocols ospf 
export export_static; 
area 0.0.0.0 { 

interface so-0/2/0.0; 


Output for R2: 


user@R2# show interfaces 
so-0/2/0 { 
unit O { 
family inet { 
address 10.0.2.2/30; 


user@R2# show policy-options 
policy-statement filter_routes { 
from { 
route-filter 10.0.16.0/30 exact; 
} 


then reject; 


user@R2# show protocols ospf 
import filter_routes; 
area 0.0.0.0 { 

interface so-0/2/0.0; 
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To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, show 
routing-options, and show protocols ospf3 commands on the appropriate device. 


Verification 


IN THIS SECTION 


@ = Verifying the OSPF Database | 499 
@ Verifying the Routing Table | 499 


Confirm that the configuration is working properly. 


Verifying the OSPF Database 


Purpose 
Verify that OSPF is advertising the static route in the OSPF database. 


Action 


From operational mode, enter the show ospf database for OSPF v2, and enter the show ospf3 database 
command for OSPFv3. 


Verifying the Routing Table 


Purpose 


Verify the entries in the routing table. 


Action 


From operational mode, enter the show route command. 


Example: Configuring a Route Filter Policy to Specify Priority for Prefixes 
Learned Through OSPF 


IN THIS SECTION 


@ ~~ Requirements | 500 
@ = Overview | 500 
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@ Configuration | 501 
@ Verification | 504 


This example shows how to create an OSPF import policy that prioritizes specific prefixes learned through 
OSPF. 


Requirements 


Before you begin: 


Configure the device interfaces. See the Interfaces User Guide for Security Devices. 


Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


Control OSPF designated router election See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Configure a single-area OSPF network. See “Example: Configuring a Single-Area OSPF Network” on 
page 76. 


Configure a multiarea OSPF network. See “Example: Configuring a Multiarea OSPF Network” on page 79. 


Overview 


In a network with a large number of OSPF routes, it can be useful to control the order in which routes are 
updated in response to a network topology change. In Junos OS Release 9.3 and later, you can specify a 
priority of high, medium, or low for prefixes included in an OSPF import policy. In the event of an OSPF 

topology change, high priority prefixes are updated in the routing table first, followed by medium and then 
low priority prefixes. 


OSPF import policy can only be used to set priority or to filter OSPF external routes. If an OSPF import 
policy is applied that results in a reject terminating action for a nonexternal route, then the reject action 
is ignored and the route is accepted anyway. By default, such a route is now installed in the routing table 
with a priority of low. This behavior prevents traffic black holes, that is, silently discarded traffic, by ensuring 
consistent routing within the OSPF domain. 


In general, OSPF routes that are not explicitly assigned a priority are treated as priority medium, except 
for the following: 


e Summary discard routes have a default priority of low. 


e Local routes that are not added to the routing table are assigned a priority of low. 


e External routes that are rejected by import policy and thus not added to the routing table are assigned 
a priority of low. 


Any available match criteria applicable to OSPF routes can be used to determine the priority. Two of the 
most commonly used match criteria for OSPF are the route-filter and tag statements. 


In this example, the routing device is in area 0.0.0.0, with interfaces fe-0/1/0 and fe-1/1/0 connecting to 
neighboring devices. You configure an import routing policy named ospf-import to specify a priority for 
prefixes learned through OSPF. Routes associated with these prefixes are installed in the routing table in 
the order of the prefixes’ specified priority. Routes matching 192.0.2.0/24 orlonger are installed first 
because they have a priority of high. Routes matching 198.51.100.0/24 orlonger are installed next because 
they have a priority of medium. Routes matching 203.0.113.0/24 orlonger are installed last because they 
have a priority of low. You then apply the import policy to OSPF. 


NOTE: The priority value takes effect when a new route is installed, or when there is a change 
to an existing route. 


Configuration 


CLI Quick Configuration 


To quickly configure an OSPF import policy that prioritizes specific prefixes learned through OSPF, copy 
the following commands, paste them into a text file, remove any line breaks, change any details necessary 
to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy 
level, and then enter commit from configuration mode. 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 192.168.8.4/30 

set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.5/30 

set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 orlonger 
set policy-options policy-statement ospf-import term t1 then priority low 

set policy-options policy-statement ospf-import term t1 then accept 

set policy-options policy-statement ospf-import term t2 from route-filter 198.51.100.0/24 orlonger 
set policy-options policy-statement ospf-import term t2 then priority medium 

set policy-options policy-statement ospf-import term t2 then accept 

set policy-options policy-statement ospf-import term t3 from route-filter 192.0.2.0/24 orlonger 
set policy-options policy-statement ospf-import term t3 then priority high 

set policy-options policy-statement ospf-import term t3 then accept 

set protocols ospf import ospf-import 

set protocols ospf area 0.0.0.0 interface fe-0/1/0 

set protocols ospf area 0.0.0.0 interface fe-1/1/0 
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Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide. 


To configure an OSPF import policy that prioritizes specific prefixes: 


1. Configure the interfaces. 


[edit] 
user@host# set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30 
user@host# set interfaces fe-0/2/0 unit O family inet address 192.168.8.5/30 


2. Enable OSPF on the interfaces. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@host# set protocols ospf area 0.0.0.0 interface fe-0/1/0 
user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/0 


3. Configure the policy to specify the priority for prefixes learned through OSPF. 


[edit ] 

user@host# set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 
orlonger 

user@host# set policy-options policy-statement ospf-import term t1 then priority low 

user@host# set policy-options policy-statement ospf-import term t1 then accept 

user@host# set policy-options policy-statement ospf-import term t2 from route-filter 198.51.100.0/24 
orlonger 

user@host# set policy-options policy-statement ospf-import term t2 then priority medium 

user@host# set policy-options policy-statement ospf-import term t2 then accept 

user@host# set policy-options policy-statement ospf-import term t3 from route-filter 192.0.2.0/24 orlonger 

user@host# set policy-options policy-statement ospf-import term t3 then priority high 

user@host# set policy-options policy-statement ospf-import term t3 then accept 


4. Apply the policy to OSPF. 


[edit] 
user@host# set protocols ospf import ospf-import 


5. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by entering the show interfaces, show policy-options, and the show protocols 
ospf commands. If the output does not display the intended configuration, repeat the instructions in this 


example to correct the configuration. 


user@host# show interfaces 
fe-0/1/0 { 
unit O { 
family inet { 
address 192.168.8.4/30; 


fe-0/2/0 { 
unit O { 
family inet { 
address 192.168.8.5/30; 


user@host# show protocols ospf 
import ospf-import; 
area 0.0.0.0 { 

interface fe-0/1/0.0; 

interface fe-0/2/0.0; 


user@host# show policy-options 
policy-statement ospf-import { 
term t1 { 
from { 
route-filter 203.0.113.0/24 orlonger; 
} 
then { 
priority low; 
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accept; 


} 
term t2 { 
from { 
route-filter 198.51.100.0/24 orlonger; 
} 
then { 
priority medium; 
accept; 


} 
term t3 { 
from { 
route-filter 192.0.2.0/24 orlonger; 
} 
then { 
priority high; 
accept; 


user@host# show protocols ospf 
import ospf-import; 
area 0.0.0.0 { 

interface fe-0/1/0.0; 

interface fe-0/2/0.0; 


To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols 
ospf3 commands. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Prefix Priority in the OSPF Routing Table 


Purpose 


Verify the priority assigned to the prefix in the OSPF routing table. 
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Action 
From operational mode, enter the show ospf route detail for OSPFv2, and enter the show ospf3 route 
detail command for OSPFv3. 


| Import and Export Policies for Network Summaries Overview 


By default, OSPF uses network-summary link-state advertisements (LSAs) to transmit route information 
across area boundaries. Each area border router (ABR) floods network-summary LSAs to other routing 
devices in the same area. The ABR also controls which routes from the area are used to generate 
network-summary LSAs into other areas. Each ABR maintains a separate topological database for each 
area to which they are connected. In Junos OS Release 9.1 and later, you can configure export and import 
policies for OSPFv2 and OSPF v3 that enable you to control how network-summary LSAs, which contain 
information about interarea OSPF prefixes, are distributed and generated. For OSPFv3, the LSA is referred 
to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for 
OSPFv2. An ABR originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an 
area. 


The export policy enables you to specify which summary LSAs are flooded into an area. The import policy 
enables you to control which routes learned from an area are used to generate summary LSAs into other 
areas. You define a routing policy at the [edit policy-options policy-statement policy-name] hierarchy level. 
As with all OSPF export policies, the default for network-summary LSA export policies is to reject everything. 
Similarly, as with all OSPF import policies, the default for network-summary LSA import policies is to accept 
all OSPF routes. 


| Example: Configuring an OSPF Export Policy for Network Summaries 


IN THIS SECTION 


Requirements | 506 
Overview | 506 
Configuration | 508 


Verification | 515 


This example shows how to create an OSPF export policy to control the network-summary (Type 3) LSAs 
that the ABR floods into an OSPF area. 
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Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 


e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71 


Overview 


OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on 
your network environment, you might want to further filter the network-summary LSAs between OSPF 
areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to 
advertise internal route information between those areas. To further improve the control of route 
distribution between multiple OSPF areas, you can configure network summary policies on the ABR for 
the area that you want to filter the advertisement of network-summary LSAs. 


NOTE: For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same 
function as anetwork-summary LSA performs for OSPFv2. An ABR originates an interarea prefix 
LSA for each IPvé6 prefix that must be advertised into an area. In this topic, the terms network 
summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 
functionality. 


The following guidelines apply to export network summary policies: 


e You should have a thorough understanding of your network before configuring these policies. Incorrect 
network summary policy configuration might result in an unintended result such as suboptimal routing 
or dropped traffic. 


e We recommend that you use the route-filter policy match condition for these types of policies. 


e We recommend that you use the accept and reject routing policy terms for these types of policies. 


Figure 27 on page 507 shows a sample topology with three OSPF areas. R4 generates network summaries 
for the routes in area 4 and sends them out of area 4 to area O. R3 generates network summaries for the 
routes in area 3 and sends them out of area 3 to area 0. 
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Figure 27: Sample Topology Used for an OSPF Export Network Summary Policy 
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In this example, you configure R4 with an export network summary policy named export-policy that only 
allows routes that match the 10.0.4.4 prefix from area 3 into area 4. The export policy controls the 
network-summary LSAs that R4 floods into area 4. This results in only the allowed interarea route to enter 
area 4, and all other interarea routes to be purged from the OSPF database and the routing table of the 
devices in area 4. You first define the policy and then apply it to the ABR by including the 
network-summary-export statement for OSPFv2 or the inter-area-prefix-export statement for OSPFv3. 


The devices operate as follows: 


e R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and 
connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2. 


e R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and 
connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.1 and connects to R3. 


e R3—Device R3 participates in area 3 and area O. R3 is the ABR between area 3 and area O, and passes 
network-summary LSAs between the areas. Interface fe-1/0/0 has an IP address of 10.0.4.2/30 and 
connects to R2. Interface fe-1/1/0 has an IP address of 10.0.4.14/30 and connects to R1. Interface 
fe-0/0/1 has an IP address of 10.0.2.1/30 and connects to R4. 


e R4—Device R4 participates in area O and area 4. R4 is the ABR between area O and area 4, and passes 
network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 10.0.2.4/30 and 
connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to R5. Interface 
fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to Ré. 


e R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and 
connects to R4. 


e R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and 
connects to R4. 


Configuration 


CLI Quick Configuration 

To quickly configure an OSPF export policy for network summaries, copy the following commands, paste 
them into a text file, remove any line breaks, change any details necessary to match your network 
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter 


commit from configuration mode. 


Configuration on Device R1: 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 10.0.4.13/30 
set interfaces fe-0/0/1 unit O family inet address 10.0.4.5/30 
set protocols ospf area 0.0.0.3 interface fe-0/1/0 

set protocols ospf area 0.0.0.3 interface fe-0/0/1 


Configuration on Device R2: 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 10.0.4.6/30 
set interfaces fe-1/0/0 unit O family inet address 10.0.4.1/30 
set protocols ospf area 0.0.0.3 interface fe-0/1/0 

set protocols ospf area 0.0.0.3 interface fe-1/0/0 


Configuration on Device R3: 


[edit] 

set interfaces fe-1/0/0 unit O family inet address 10.0.4.2/30 
set interfaces fe-1/1/0 unit O family inet address 10.0.4.14/30 
set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 
set protocols ospf area 0.0.0.3 interface fe-1/0/0 

set protocols ospf area 0.0.0.3 interface fe-1/1/0 

set protocols ospf area 0.0.0.0 interface fe-0/0/1 


Configuration on Device R4: 


[edit] 

set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 

set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30 

set interfaces fe-1/0/0 unit O family inet address 10.0.8.9/30 

set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30 prefix-length-range 
/30-/30 

set policy-options policy-statement export-policy term term1 then accept 
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set protocols ospf area 0.0.0.0 interface fe-0/0/1 
set protocols ospf area 0.0.0.4 interface fe-0/1/0 
set protocols ospf area 0.0.0.4 interface fe-1/0/0 
set protocols ospf area 0.0.0.4 network-summary-export export-policy 


Configuration on Device R5: 


[edit] 
set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30 
set protocols ospf area 0.0.0.4 interface fe-0/1/0 


Configuration on Device Ré: 


[edit] 
set interfaces fe-1/0/0 unit O family inet address 10.0.8.10/30 
set protocols ospf area 0.0.0.4 interface fe-1/0/0 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide. 


To configure an configure an OSPF export policy for network summaries: 


1. Configure the interfaces. 


NOTE: For OSPFv3, use IPvé6 addresses. 


[edit] 
user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 
user@R1# set interfaces fe-0/0/1 unit O family inet address 10.0.4.5/30 


[edit] 
user@R2# set interfaces fe-0/1/0 unit O family inet address 10.0.4.6/30 
user@R2# set interfaces fe-1/0/0 unit O family inet address 10.0.4.1/30 


[edit] 
user@R3# set interfaces fe-1/0/0 unit O family inet address 10.0.4.2/30 
user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 
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user@R3#set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 


[edit] 

user@R4# set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 
user@R4# set interfaces fe-1/1/0 unit O family inet address 10.0.8.6/30 
user@R4# set interfaces fe-1/0/0 unit O family inet address 10.0.8.9/30 


[edit] 
user@R5# set interfaces fe-1/1/0 unit O family inet address 10.0.8.5/30 


[edit] 
user@R6# set interfaces fe-1/0/0 unit O family inet address 10.0.8.10/30 


2. Enable OSPF on the interfaces. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0 
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1 


[edit] 
user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0 
user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0 


[edit] 

user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0 
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0 
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1 


[edit] 

user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1 
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0 
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0 
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[edit] 
user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0 


[edit] 
user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 


3. On R4, configure the export network summary policy. 


[edit ] 

user@R4# set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30 
prefix-length-range /30-/30 

user@R4# set policy-options policy-statement export-policy term term1 then accept 


4. On R4, apply the export network summary policy to OSPF. 


NOTE: For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols 
ospf3 area area-id] hierarchy level. 


[edit] 
user@R4# set protocols ospf area 0.0.0.4 network-summary-export export-policy 


5. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols 
ospf commands on the appropriate device. If the output does not display the intended configuration, 
repeat the instructions in this example to correct the configuration. 


Output for R1: 
user@R1# show interfaces 


fe-0/0/1 { 
unit O { 


family inet { 
address 10.0.4.5/30; 
} 
} 
} 
fe-1/1/0 { 
unit O { 
family inet { 
address 10.0.4.13/30; 
} 
} 
} 


user@R1# show protocols ospf 
area 0.0.0.3 { 
interface fe-0/1/0.0; 
interface fe-0/0/1.0; 


Output for R2: 


user@R2# show interfaces 
fe-0/1/0 { 
unit O { 
family inet { 
address 10.0.4.6/30; 


} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.4.3/30; 


user@R2# show protocols ospf 
area 0.0.0.3 { 
interface fe-0/1/0.0; 
interface fe-1/0/0.0; 
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Output for R3: 


user@R3# show interfaces 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.2.3/30; 


} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.4.2/30; 


} 
fe-1/1/0 { 
unit O { 
family inet { 
address 10.0.4.14/30; 


user@R3# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0; 


area 0.0.0.3 { 
interface fe-1/0/0.0; 
interface fe-1/1/0.0; 


Output for R4: 


user@R4# show interfaces 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.2.4/30; 
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} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.8.6/30; 


} 
fe-1/1/0 { 
unit O { 
family inet { 
address 10.0.8.3/30; 


user@R4# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0; 
} 
area 0.0.0.4 { 
network-summary-export export-policy; 
interface fe-1/0/0.0; 
interface fe-1/1/0.0; 


user@R4# show policy-options 
policy-statement export-policy { 
term term1 { 
from { 
route-filter 10.0.4.4/30 prefix-length-range /30-/30; 
} 


then accept; 


Output for R5: 


user@R5# show interfaces 
fe-1/1/0 { 
unit O { 
family inet { 
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address 10.0.8.5/30; 


user@R5# show protocols ospf 
area 0.0.0.4 { 
interface fe-1/1/0.0; 


Output for R6: 


user@R6# show interfaces 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.8.7/30; 


user@R6# show protocols ospf 
area 0.0.0.4 { 
interface fe-1/0/0.0; 


To confirm your OSPF v3 configuration, enter the show interfaces, show policy-options, and show protocols 
ospf3 commands on the appropriate device. 


Verification 


IN THIS SECTION 


@ Verifying the OSPF Database | 516 
@ Verifying the Routing Table | 516 


Confirm that the configuration is working properly. 
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Verifying the OSPF Database 


Purpose 


Verify that the OSPF database for the devices in area 4 includes the interarea route that we permitted on 
the ABR R4. The other interarea routes that are not specified should age out or no longer be present in 
the OSPF database. 


Action 
From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, 
and enter the show ospf3 database inter-area-prefix area 0.0.0.4 command for OSPFv3. 


Verifying the Routing Table 


Purpose 


Verify that the routes corresponding to the rejected network summaries are no longer present in R4’s, 
R5’s, or R6é’s routing table. 


Action 


From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3. 


Example: Configuring an OSPF Import Policy for Network Summaries 


IN THIS SECTION 


Requirements | 516 
Overview | 517 
Configuration | 519 


Verification | 526 


This example shows how to create an OSPF import policy to control the network-summary (Type 3) LSAs 
that the ABR advertises out of an OSPF area. 


Requirements 


Before you begin: 


e Configure the router identifiers for the devices in your OSPF network. See “Example: Configuring an 
OSPF Router Identifier” on page 69. 
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e Control OSPF designated router election. See “Example: Controlling OSPF Designated Router Election” 
on page 71. 


Overview 


OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on 
your network environment, you might want to further filter the network-summary LSAs between OSPF 
areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to 
advertise internal route information between those areas. To further improve the control of route 
distribution between multiple OSPF areas, you can configure network summary policies on the ABR for 
the area that you want to filter the advertisement of network-summary LSAs. 


NOTE: For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same 
function as anetwork-summary LSA performs for OSPFv2. An ABR originates an interarea prefix 
LSA for each IPvé6 prefix that must be advertised into an area. In this topic, the terms network 
summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 
functionality. 


The following guidelines apply to import network summary policies: 


e You should have a thorough understanding of your network before configuring these policies. Incorrect 
network summary policy configuration might result in an unintended result such as suboptimal routing 
or dropped traffic. 


e We recommend that you use the route-filter policy match condition for these types of policies. 


e We recommend that you use the accept and reject routing policy terms for these types of policies. 


Figure 28 on page 518 shows a sample topology with three OSPF areas. R4 generates network summaries 
for the routes in area 4 and sends them out of area 4 to area O. R3 generates network summaries for the 
routes in area 3 and sends them out of area 3 to area 0. 


518 


Figure 28: Sample Topology Used for an OSPF Import Network Summary Policy 
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In this example, you configure R3 with an import network summary policy named import-policy so R3 only 
generates network summaries for the route 10.0.4.12/30. The import policy controls the routes and 
therefore the network summaries that R3 advertises out of area 3, so applying this policy means that R3 
only advertises route 10.0.4.12/30 out of area 3. This results in existing network summaries from other 
interarea routes getting purged from the OSPF database in area O and area 4, as well as the routing tables 
of the devices in areas O and area 4. You first define the policy and then apply it to the ABR by including 
the network-summary-import statement for OSPF v2 or the inter-area-prefix-import statement for OSPFv3. 


The devices operate as follows: 


e R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and 
connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2. 


e R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and 
connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.1/30 and connects to R3. 


e R3—Device R3 participates in area 3 and area O. R3 is the ABR between area 3 and area O, and passes 
network-summary LSAs between the areas. Interface fe-1/0/0 has an IP address of 10.0.4.2/30 and 
connects to R2. Interface fe-1/1/0 has an IP address of 10.0.4.14/30 and connects to R1. Interface 
fe-0/0/1 has an IP address of 10.0.2.1/30 and connects to R4. 


e R4—Device R4 participates in area O and area 4. R4 is the ABR between area O and area 4, and passes 
network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 10.0.2.1/30 and 
connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to R5. Interface 
fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to Ré. 


e R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and 
connects to R4. 


e R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and 
connects to R4. 


Configuration 


CLI Quick Configuration 

To quickly configure an OSPF import policy for network summaries, copy the following commands, paste 
them into a text file, remove any line breaks, change any details necessary to match your network 
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter 


commit from configuration mode. 


Configuration on Device R1: 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 10.0.4.13/30 
set interfaces fe-0/0/1 unit O family inet address 10.0.4.5/30 
set protocols ospf area 0.0.0.3 interface fe-0/1/0 

set protocols ospf area 0.0.0.3 interface fe-0/0/1 


Configuration on Device R2: 


[edit] 

set interfaces fe-0/1/0 unit O family inet address 10.0.4.6/30 
set interfaces fe-1/0/0 unit O family inet address 10.0.4.1/30 
set protocols ospf area 0.0.0.3 interface fe-0/1/0 

set protocols ospf area 0.0.0.3 interface fe-1/0/0 


Configuration on Device R3: 


[edit] 

set interfaces fe-1/0/0 unit O family inet address 10.0.4.2/30 

set interfaces fe-1/1/0 unit O family inet address 10.0.4.14/30 

set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 

set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30 prefix-length-range 
/30-/30 

set policy-options policy-statement import-policy term term1 then accept 

set protocols ospf area 0.0.0.3 interface fe-1/0/0 

set protocols ospf area 0.0.0.3 interface fe-1/1/0 

set protocols ospf area 0.0.0.0 interface fe-0/0/1 

set protocols ospf area 0.0.0.3 network-summary-import import-policy 


Configuration on Device R4: 


[edit] 
set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 
set interfaces fe-1/1/0 unit O family inet address 10.0.8.6/30 
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set interfaces fe-1/0/0 unit O family inet address 10.0.8.9/30 
set protocols ospf area 0.0.0.0 interface fe-0/0/1 
set protocols ospf area 0.0.0.4 interface fe-1/1/0 
set protocols ospf area 0.0.0.4 interface fe-1/0/0 


Configuration on Device R5: 


[edit] 
set interfaces fe-1/1/0 unit O family inet address 10.0.8.5/30 
set protocols ospf area 0.0.0.4 interface fe-1/1/0 


Configuration on Device Ré: 


[edit] 
set interfaces fe-1/0/0 unit O family inet address 10.0.8.10/30 
set protocols ospf area 0.0.0.4 interface fe-1/0/0 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide. 


To configure an configure an OSPF import policy for network summaries: 


1. Configure the interfaces. 


NOTE: For OSPFv3, use IPv6 addresses. 


[edit] 
user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30 
user@R1# set interfaces fe-0/0/1 unit O family inet address 10.0.4.5/30 


[edit] 
user@R2# set interfaces fe-0/1/0 unit O family inet address 10.0.4.6/30 
user@R2# set interfaces fe-1/0/0 unit O family inet address 10.0.4.1/30 


[edit] 
user@R3# set interfaces fe-1/0/0 unit O family inet address 10.0.4.2/30 
user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30 
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user@R3#set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 


[edit] 

user@R4# set interfaces fe-0/0/1 unit O family inet address 10.0.2.1/30 
user@R4# set interfaces fe-1/1/0 unit O family inet address 10.0.8.6/30 
user@R4# set interfaces fe-1/0/0 unit O family inet address 10.0.8.9/30 


[edit] 
user@R5# set interfaces fe-1/1/0 unit O family inet address 10.0.8.5/30 


[edit] 
user@R6# set interfaces fe-1/0/0 unit O family inet address 10.0.8.10/30 


2. Enable OSPF on the interfaces. 


NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level. 


[edit] 
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0 
user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1 


[edit] 
user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0 
user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0 


[edit] 

user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0 
user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0 
user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1 


[edit] 

user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1 
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0 
user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0 
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[edit] 
user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0 


[edit] 
user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 


3. On R3, configure the import network summary policy. 


[edit ] 

user@R3# set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30 
prefix-length-range /30-/30 

user@R3# set policy-options policy-statement import-policy term term1 then accept 


4. On R3, apply the import network summary policy to OSPF. 


NOTE: For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols 
ospf3 area area-id] hierarchy level. 


[edit] 
user@R3# set protocols ospf area 0.0.0.3 network-summary-import import-policy 


5. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 


Results 

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols 
ospf commands on the appropriate device. If the output does not display the intended configuration, 
repeat the instructions in this example to correct the configuration. 


Output for R1: 
user@R1# show interfaces 


fe-0/0/1 { 
unit O { 


family inet { 
address 10.0.4.5/30; 
} 
} 
} 
fe-0/1/0 { 
unit O { 
family inet { 
address 10.0.4.13/30; 
} 
} 
} 


user@R1# show protocols ospf 
area 0.0.0.3 { 
interface fe-0/1/0.0; 
interface fe-0/0/1.0; 


Output for R2: 


user@R2# show interfaces 
fe-0/1/0 { 
unit O { 
family inet { 
address 10.0.4.6/30; 


} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.4.1/30; 


user@R2# show protocols ospf 
area 0.0.0.3 { 
interface fe-0/1/0.0; 
interface fe-1/0/0.0; 
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Output for R3: 


user@R3# show interfaces 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.2.1/30; 


} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.4.2/30; 


} 
fe-1/1/0 { 
unit O { 
family inet { 
address 10.0.4.14/30; 


user@R3# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0; 


area 0.0.0.3 { 
network-summary-import import policy; 
interface fe-1/0/0.0; 
interface fe-1/1/0.0; 


user@R3# show policy-options 
policy-statement import-policy { 
term term1 { 
from { 
route-filter 10.0.4.12/30 prefix-length-range /30-/30; 
} 


then accept; 
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Output for R4: 


user@R4# show interfaces 
fe-0/0/1 { 
unit O { 
family inet { 
address 10.0.2.1/30; 


} 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.8.9/30; 


} 
fe-1/1/0 { 
unit O { 
family inet { 
address 10.0.8.6/30; 


user@R4# show protocols ospf 
area 0.0.0.0 { 
interface fe-0/0/1.0; 
} 
area 0.0.0.4 { 
interface fe-0/1/0.0; 
interface fe-1/0/0.0; 


Output for R5: 


user@R5# show interfaces 
fe-1/1/0 { 
unit O { 
family inet { 
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address 10.0.8.5/30; 


user@R5# show protocols ospf 
area 0.0.0.4 { 
interface fe-1/1/0.0; 


Output for R6: 


user@R6# show interfaces 
fe-1/0/0 { 
unit O { 
family inet { 
address 10.0.8.10/30; 


user@R6# show protocols ospf 
area 0.0.0.4 { 
interface fe-1/0/0.0; 


To confirm your OSPF v3 configuration, enter the show interfaces, show policy-options, and show protocols 
ospf3 commands on the appropriate device. 


Verification 


IN THIS SECTION 


@ = Verifying the OSPF Database | 527 
@ Verifying the Routing Table | 527 


Confirm that the configuration is working properly. 
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Verifying the OSPF Database 


Purpose 

Verify that the OSPF database for the devices in area 4 includes the interarea route that we are advertising 
from R3. Any other routes from area 3 should not be advertised into area 4, so those entries should age 
out or no longer be present in the OSPF database. 


Action 
From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, 
and enter the show ospf3 database inter-area-prefix area 0.0.0.4 command for OSPFv3. 


Verifying the Routing Table 


Purpose 
Verify that the specified route is included in R4’s, R5’s, or R6’s routing table. Any other routes from area 
3 should not be advertised into area 4. 


Action 


From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3. 


Example: Redistributing OSPF Routes into IS-IS 


IN THIS SECTION 


Requirements | 527 
Overview | 527 
Configuration | 528 


Verification | 536 


This example shows how to redistribute OSPF routes into an IS-IS network. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


Export policy can be applied to IS-IS to facilitate route redistribution. 


Junos OS does not support the application of import policy for link-state routing protocols like IS-IS because 
such policies can lead to inconsistent link-state database (LSDB) entries, which in turn can result in routing 
inconstancies. 


In this example, OSPF routes 192.168.0/24 through 192.168.3/24 are redistributed into IS-IS area 49.0002 
from Device R2. 


In addition, policies are configured to ensure that Device R1 can reach destinations on the 10.0.0.44/30 
network, and that Device R3 can reach destinations on the 10.0.0.36/30 network. This enables end-to-end 
reachability. 


Figure 29 on page 528 shows the topology used in this example. 


Figure 29: IS-IS Route Redistribution Topology 
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“CLI Quick Configuration” on page 528 shows the configuration for all of the devices in Figure 29 on page 528. 
The section “Step-by-Step Procedure” on page 530 describes the steps on Device R2. “Step-by-Step 
Procedure” on page 532 describes the steps on Device R3. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device R1 
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set interfaces fe-1/2/0 unit O description to-R7 

set interfaces fe-1/2/0 unit O family inet address 10.0.0.38/30 

set interfaces fe-1/2/0 unit 0 family iso 

set interfaces loO unit 0 family inet address 172.16.3.5/32 

set interfaces loO unit O family iso address 49.0002.0172.0016.0305.00 
set protocols isis interface fe-1/2/0.0 

set protocols isis interface lo0.0 


Device R2 


set interfaces fe-1/2/1 unit O description to-R5 

set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.37/30 

set interfaces fe-1/2/1 unit 0 family iso 

set interfaces fe-1/2/0 unit O description to-OSPF-network 

set interfaces fe-1/2/0 unit O family inet address 10.0.0.45/30 

set interfaces loO unit O family inet address 172.16.9.7/32 

set interfaces loO unit O family iso address 49.0002.0172.0016.0907.00 

set protocols isis export ospf-isis 

set protocols isis export send-direct-to-isis-neighbors 

set protocols isis interface fe-1/2/1.0 

set protocols isis interface lo0.0 

set protocols ospf export send-direct-to-ospf-neighbors 

set protocols ospf area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.1 interface lo0.0 passive 

set policy-options policy-statement ospf-isis term 1 from protocol ospf 

set policy-options policy-statement ospf-isis term 1 from route-filter 192.168.0.0/22 longer 

set policy-options policy-statement ospf-isis term 1 then accept 

set policy-options policy-statement send-direct-to-isis-neighbors from protocol direct 

set policy-options policy-statement send-direct-to-isis-neighbors from route-filter 10.0.0.44/30 exact 

set policy-options policy-statement send-direct-to-isis-neighbors then accept 

set policy-options policy-statement send-direct-to-ospf-neighbors from protocol direct 

set policy-options policy-statement send-direct-to-ospf-neighbors from route-filter 10.0.0.36/30 
exact 

set policy-options policy-statement send-direct-to-ospf-neighbors then accept 


Device R3 
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set interfaces fe-1/2/0 unit O family inet address 10.0.0.46/30 
set interfaces loO unit O family inet address 192.168.1.1/32 
set interfaces loO unit O family inet address 192.168.2.1/32 
set interfaces loO unit O family inet address 192.168.3.1/32 
set interfaces loO unit O family inet address 192.168.0.1/32 
set protocols ospf export ospf 

set protocols ospf area 0.0.0.1 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.1 interface lo0.0 passive 

set policy-options policy-statement ospf term 1 from protocol static 
set policy-options policy-statement ospf term 1 then accept 
set routing-options static route 192.168.0.0/24 discard 

set routing-options static route 192.168.1.0/24 discard 

set routing-options static route 192.168.3.0/24 discard 

set routing-options static route 192.168.2.0/24 discard 


Step-by-Step Procedure 


To configure Device R2: 


1. Configure the network interfaces. 


[edit interfaces] 

user@R2# set fe-1/2/1 unit O description to-R5 

user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.37/30 
user@R2# set fe-1/2/1 unit O family iso 

user@R2# set fe-1/2/0 unit O description to-OSPF-network 

user@R2# set fe-1/2/0 unit O family inet address 10.0.0.45/30 
user@R2# set loO unit O family inet address 172.16.9.7/32 

user@R2# set loO unit O family iso address 49.0002.0172.0016.0907.00 


2. Configure IS-IS on the interface facing Device R1 and the loopback interface. 


[edit protocols isis] 
user@R2# set interface fe-1/2/1.0 
user@R2# set interface lo0.0 


3. Configure the policy that enables Device R1 to reach the 10.0.0.44/30 network. 


[edit policy-options policy-statement send-direct-to-isis-neighbors] 
user@R2# set from protocol direct 


user@R2# set from route-filter 10.0.0.44/30 exact 
user@R2# set then accept 


4. Apply the policy that enables Device R1 to reach the 10.0.0.44/30 network. 


[edit protocols isis] 
user@R2# set export send-direct-to-isis-neighbors 


5. Configure OSPF on the interfaces. 


[edit protocols ospf] 
user@R2# set area 0.0.0.1 interface fe-1/2/0.0 
user@R2# set area 0.0.0.1 interface lo0.0 passive 


6. Configure the OSPF route redistribution policy. 


[edit policy-options policy-statement ospf-isis term 1] 
user@R2# set from protocol ospf 

user@R2# set from route-filter 192.168.0.0/22 longer 
user@R2# set then accept 


7. Apply the OSPF route redistribution policy to the IS-IS instance. 


[edit protocols isis] 
user@R2# set export ospf-isis 


8. Configure the policy that enables Device R3 to reach the 10.0.0.36/30 network. 


[edit policy-options policy-statement send-direct-to-ospf-neighbors] 
user@R2# set from protocol direct 

user@R2# set from route-filter 10.0.0.36/30 exact 

user@R2# set then accept 


9. Apply the policy that enables Device R3 to reach the 10.0.0.36/30 network. 


[edit protocols ospf] 
user@R2# set export send-direct-to-ospf-neighbors 
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Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure multi-level IS-IS: 


1. Configure the network interfaces. 


Multiple addresses are configured on the loopback interface to simulate multiple route destinations. 


[edit interfaces] 

user@R3# set fe-1/2/0 unit 0 family inet address 10.0.0.46/30 
user@R3# set loO unit O family inet address 192.168.1.1/32 
user@R3# set loO unit O family inet address 192.168.2.1/32 
user@R3# set loO unit O family inet address 192.168.3.1/32 
user@R3# set loO unit O family inet address 192.168.0.1/32 


2. Configure static routes to the loopback interface addresses. 


These are the routes that are redistributed into IS-IS. 


[edit routing-options static] 

user@R3# set route 192.168.0.0/24 discard 
user@R3# set route 192.168.1.0/24 discard 
user@R3# set route 192.168.3.0/24 discard 
user@R3# set route 192.168.2.0/24 discard 


3. Configure OSPF on the interfaces. 


[edit protocols ospf area 0.0.0.1] 
user@R3# set interface fe-1/2/0.0 
user@R3# set interface lo0.0 passive 


4. Configure the OSPF policy to export the static routes. 


[edit policy-options policy-statement ospf term 1] 
user@R3# set from protocol static 
user@R3# set then accept 


5. Apply the OSPF export policy. 


[edit protocols ospf] 


user@R3# set export ospf 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


Device R2 


user@R2# show interfaces 
fe-1/2/1 { 
unit O { 
description to-R5; 
family inet { 
address 10.0.0.37/30; 
} 


family iso; 


} 
fe-1/2/0 { 
unit O { 
description to-OSPF-network; 
family inet { 
address 10.0.0.45/30; 


} 
loO { 
unit O { 
family inet { 
address 172.16.9.7/32; 
} 
family iso { 
address 49.0002.0172.0016.0907.00; 


user@R2# show protocols 
isis { 
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export [ ospf-isis send-direct-to-isis-neighbors ]; 
interface fe-1/2/1.0,; 
interface 100.0; 
} 
ospf { 
export send-direct-to-ospf-neighbors; 
area 0.0.0.1 { 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


user@R2# show policy-options 
policy-statement ospf-isis { 
term 1 { 
from { 
protocol ospf; 
route-filter 192.168.0.0/22 longer; 
} 


then accept; 


} 
policy-statement send-direct-to-isis-neighbors { 
from { 
protocol direct; 
route-filter 10.0.0.44/30 exact; 
} 
then accept; 
} 
policy-statement send-direct-to-ospf-neighbors { 
from { 
protocol direct; 
route-filter 10.0.0.36/30 exact; 
} 


then accept; 


Device R3 
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user@R3# show interfaces 
fe-1/2/0 { 
unit O { 
family inet { 
address 10.0.0.46/30; 


} 
loO { 
unit O { 
family inet { 

address 192.168.1.1/32; 
address 192.168.2.1/32; 
address 192.168.3.1/32; 
address 192.168.0.1/32; 


user@R3# show protocols 
ospf { 
export ospf; 
area 0.0.0.1 { 
interface fe-1/2/0.0; 
interface 100.0 { 


passive; 


user@R3# show policy-options 
policy-statement ospf { 
term 1 { 
from protocol static; 
then accept; 


user@R3# show routing-options 
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static { 
route 192.168.0.0/24 discard; 
route 192.168.1.0/24 discard; 
route 192.168.3.0/24 discard; 
route 192.168.2.0/24 discard; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Verifying OSPF Route Advertisement | 536 
@ Verifying Route Redistribution | 537 
@ Verifying Connectivity | 538 


Confirm that the configuration is working properly. 


Verifying OSPF Route Advertisement 


Purpose 


Make sure that the expected routes are advertised by OSPF. 


Action 


From operational mode on Device R2, enter the show route protocol ospf command. 


user@R2> show route protocol ospf 


inet.0: 15 destinations, 15 routes (15 active, 0 holddown, O hidden) 
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Meaning 
The 192.168/16 routes are advertised by OSPF. 
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Verifying Route Redistribution 


Purpose 
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active, 0 holddown, O hidden) 


Make sure that the expected routes are redistributed from OSPF into IS-IS. 


Action 


From operational mode on Device R1, enter the show route protocol isis command. 


user@R1> show route protocol isis 


13 destinations, 








inet .0: 

+ = Active Rout 
10.0.0.44/30 
WIZ 16.900 / BZ 
192.168.0.0/24 
19/2 168 0.17/32 
192.168.1.0/24 








13 routes 


5 Last Active, 


“(IS-18/1 


* (IS-1S/ 


* (IS-1S/ 





> co 10, 
2 EESS Salk 
> tO iO. 
160] 
> t@ 10. 
160] 
> tO LO. 


160] 


0.0. 


OROR 


OROR 








* (IS-1S/ 


160] 


OS 
0.0.37 via fe-1/2/0.0 
5] WSsAea, imneciire i110) 


37 


OSs 


37 


O38 


37 


OS 


(13 active, 0 holddown, O hidden) 


= = Jekone la) 


ARS 2A, imcwie 20 


via fe-1/2/0.0 
49:46, metric 10 
via fe-1/2/0.0 
AQSAG,. wesc: Ii, 
via fe-1/2/0.0 
49:46, metric 10 


cage i 


537 





192.168. 
192.168. 
192.168. 
192.168. 
192.168. 
BESORRON 
Meaning 





1 1/32 


2.0/24 


Body Be 


3.0/24 


31/32 


1 desti 


2 ce 10.0.0. 


([TS=15/L6C 
> t@ 10.0. 
= [TS=19/ LOC 
ac Om OnOr 
© [IS=18/ 16C 
> co 10,0. 
GS Ss eO 
eon OnOre 
*[IS-1S/160 
> co LOO. 














02 


nations, 1 routes 


OF 


OQ. 


OQ. 


OF 


37 


O35 


37 


O38 


37 


Ok 


Si7/ 


OSs 


37 


OS 


37 


via fe-1/2/0.0 


q 


q 


q 


q 





q 


OF aACr, 


via fe-1/2/0.0 


OF TACr 


via fe-1/2/0.0 


9:46, 


via fe-1/2/0.0 


9346, 


via fe-1/2/0.0 


ONTAICy, 


meciete Til, tac i 


metric 10 


meiciene Wil, tag i 


metric 10 





metic ii, tage i 


via fe-1/2/0.0 


active, 


The 192.168/16 routes are redistributed into IS-IS. 


Verifying Connectivity 


Purpose 


0 holddown, O hidden) 


Check that Device R1 can reach the destinations on Device R3. 


Action 


From operational mode, enter the ping command. 


user@R1> ping 192.168.1.1 


IRILINIE; IL (V2) 5 ILGie)y AL 


64 bytes from 


64 bytes from 


64 bytes from 


Meaning 


al (19251685161) 


56 data bytes 
192.168.1.1: icmp_seq=0 tt1l=63 time=2.089 ms 








192.168.1.1: icmp_seq=1 ttl=63 time=1.270 ms 
192.168.1.1: icmp_seq=2 ttl=63 time=2.135 ms 





These results confirm that Device R1 can reach the destinations in the OSPF network. 


Release History Table 


Release 


19.3R1 


Description 


Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent 


TI-LFA backup paths where the prefix SID is learned from a segment routing mapping server 


advertisement when the PLR and mapping server are both in the same OSPF area. 
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Configuring OSPFv2 Sham Links 


IN THIS SECTION 


@ OSPFv2 Sham Links Overview | 541 
@ Example: Configuring OSPFv2 Sham Links | 542 


| OSPFv2 Sham Links Overview 


You can create an intra-area link or sham link between two provider edge (PE) routing devices so that the 
VPN backbone is preferred over the back-door link. A back-door link is a backup link that connects customer 
edge (CE) devices in case the VPN backbone is unavailable. When such a backup link is available and the 
CE devices are in the same OSPF area, the default behavior is to prefer this backup link over the VPN 
backbone. This is because the backup link is considered an intra-area link, while the VPN backbone is 
always considered an interarea link. Intra-area links are always preferred over interarea links. 


The sham link is an unnumbered point-to-point intra-area link between PE devices. When the VPN backbone 
has a sham intra-area link, this sham link can be preferred over the backup link if the sham link has a lower 
OSPF metric than the backup link. 


The sham link is advertised using Type 1 link-state advertisements (LSAs). Sham links are valid only for 
routing instances and OSPFv2. 


Each sham link is identified by the combination of a local endpoint address and a remote endpoint address. 
Figure 30 on page 541 shows an OSPFv2 sham link. Router CE1 and Router CE2 are located in the same 
OSPF v2 area. These customer edge (CE) routing devices are linked together by a Layer 3 VPN over Router 
PE1 and Router PE2. In addition, Router CE1 and Router CE2 are connected by an intra-area link used as 
a backup. 


Figure 30: OSPFv2 Sham Link 


OSPF Sham Link 








Intra-Area Link 
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OSPF v2 treats the link through the Layer 3 VPN as an interarea link. By default, OSPFv2 prefers intra-area 
links to interarea links, so OSPFv2 selects the backup intra-area link as the active path. This is not acceptable 
in a configuration where the intra-area link is not the expected primary path for traffic between the CE 
routing devices. You can configure the metric for the sham link to ensure that the path over the Layer 3 
VPN is preferred to a backup path over an intra-area link connecting the CE routing devices. 


For the remote endpoint, you can configure the OSPFv2 interface as a demand circuit, configure IPsec 
authentication (you configure the actual IPsec authentication separately), and define the metric value. 


You should configure an OSPFv2 sham link under the following circumstances: 


e Two CE routing devices are linked together by a Layer 3 VPN. 
e These CE routing devices are in the same OSPFv2 area. 


e An intra-area link is configured between the two CE routing devices. 


If there is no intra-area link between the CE routing devices, you do not need to configure an OSPFv2 
sham link. 


NOTE: In Junos OS Release 9.6 and later, an OSPFv2 sham link is installed in the routing table 
as a hidden route. Additionally, a BGP route is not exported to OSPF v2 if a corresponding OSPF 
sham link is available. 


NOTE: In Junos OS Release 16.1 and later, OSPF sham-links are supported on default instances. 
The cost of the sham-link is dynamically set to the aigp-metric of the BGP route if no metric is 
configured on the sham-link by the user. If the aigp-metric is not present in the BGP route then 
the sham-link cost defaults to 1. 


| Example: Configuring OSPFv2 Sham Links 


IN THIS SECTION 


Requirements | 543 
Overview | 543 
Configuration | 544 


Verification | 551 
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This example shows how to enable OSPFv2 sham links on a PE routing device. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


The sham link is an unnumbered point-to-point intra-area link and is advertised by means of a type 1 
link-state advertisement (LSA). Sham links are valid only for routing instances and OSPF v2. 


Each sham link is identified by a combination of the local endpoint address and a remote endpoint address 
and the OSPF v2 area to which it belongs. You manually configure the sham link between two PE devices, 
both of which are within the same VPN routing and forwarding (VRF) routing instance, and you specify 
the address for the local end point of the sham link. This address is used as the source for the sham link 
packets and is also used by the remote PE routing device as the sham link remote end point. You can also 
include the optional metric option to set a metric value for the remote end point. The metric value specifies 
the cost of using the link. Routes with lower total path metrics are preferred over those with higher path 
metrics. 


To enable OSPFv2 sham links on a PE routing device: 


e Configure an extra loopback interface on the PE routing device. 


e Configure the VRF routing instance that supports Layer 3 VPNs on the PE routing device, and associate 
the sham link with an existing OSPF area. The OSPFv2 sham link configuration is also included in the 
routing instance. You configure the sham link’s local endpoint address, which is the loopback address 
of the local VPN, and the remote endpoint address, which is the loopback address of the remote VPN. 
In this example, the VRF routing instance is named red. 


Figure 31 on page 544 shows an OSPFv2 sham link. 
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Figure 31: OSPFv2 Sham Link Example 
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The devices in the figure represent the following functions: 


e CE1 and CE2 are the customer edge devices. 
e PE1 and PE2 are the provider edge devices. 


e P is the provider device. 


“CLI Quick Configuration” on page 544 shows the configuration for all of the devices in Figure 31 on page 544, 
The section “Step-by-Step Procedure” on page 547describes the steps on Device PE1. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


CE1 


set interfaces fe-1/2/0 unit O family inet address 10.1.1.1/30 

set interfaces fe-1/2/0 unit 0 family mpls 

set interfaces fe-1/2/1 unit O family inet address 10.0.0.17/30 

set interfaces loO unit O family inet address 192.0.2.1/24 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100 

set policy-options policy-statement send-direct from protocol direct 


PE1 


set policy-options policy-statement send-direct then accept 
set routing-options router-id 192.0.2.1 
set routing-options autonomous-system 1 


set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.2/30 

set interfaces fe-1/2/0 unit 0 family mpls 

set interfaces fe-1/2/1 unit O family inet address 10.1.1.5/30 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 192.0.2.2/24 

set interfaces loO unit 1 family inet address 198.51.100.2/24 

set protocols mpls interface fe-1/2/1.0 

set protocols bgp group toR4 type internal 

set protocols bgp group toR4 local-address 192.0.2.2 

set protocols bgp group toR4 family inet-vpn unicast 

set protocols bgp group toR4 neighbor 192.0.2.4 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface fe-1/2/1.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp 
set policy-options policy-statement bgp-to-ospf term 1 then accept 

set policy-options policy-statement bgp-to-ospf term 2 then reject 

set routing-instances red instance-type vrf 

set routing-instances red interface fe-1/2/0.0 

set routing-instances red interface lo0.1 

set routing-instances red route-distinguisher 2:1 

set routing-instances red vrf-target target:2:1 

set routing-instances red protocols ospf export bgp-to-ospf 

set routing-instances red protocols ospf sham-link local 198.51.100.2 
set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 
set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0 
set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 

set routing-options router-id 192.0.2.2 

set routing-options autonomous-system 2 
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PE2 


set interfaces fe-1/2/0 unit O family inet address 10.1.1.6/30 
set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.9/30 
set interfaces fe-1/2/1 unit O family mpls 

set interfaces loO unit 3 family inet address 192.0.2.3/24 

set protocols mpls interface all 

set protocols ospf area 0.0.0.0 interface lo0.3 passive 

set protocols ospf area 0.0.0.0 interface all 

set protocols Idp interface all 

set routing-options router-id 192.0.2.3 


set interfaces fe-1/2/0 unit O family inet address 10.1.1.10/30 

set interfaces fe-1/2/0 unit 0 family mpls 

set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.13/30 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 192.0.2.4/32 

set interfaces loO unit 1 family inet address 198.51.100.4/32 

set protocols mpls interface fe-1/2/0.0 

set protocols bgp group toR2 type internal 

set protocols bgp group toR2 local-address 192.0.2.4 

set protocols bgp group toR2 family inet-vpn unicast 

set protocols bgp group toR2 neighbor 192.0.2.2 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols Idp interface fe-1/2/0.0 

set protocols Idp interface lo0.0 

set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp 
set policy-options policy-statement bgp-to-ospf term 1 then accept 

set policy-options policy-statement bgp-to-ospf term 2 then reject 

set routing-instances red instance-type vrf 

set routing-instances red interface fe-1/2/1.0 

set routing-instances red interface lo0.1 

set routing-instances red route-distinguisher 2:1 

set routing-instances red vrf-target target:2:1 

set routing-instances red protocols ospf export bgp-to-ospf 

set routing-instances red protocols ospf sham-link local 198.51.100.4 
set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.2 metric 10 
set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0 
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set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 
set routing-options router-id 192.0.2.4 
set routing-options autonomous-system 2 


CE2 


set interfaces fe-1/2/0 unit 14 family inet address 10.1.1.14/30 
set interfaces fe-1/2/0 unit 14 family mpls 

set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30 
set interfaces loO unit 5 family inet address 192.0.2.5/24 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.14 

set protocols ospf area 0.0.0.0 interface lo0.5 passive 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.18 

set policy-options policy-statement send-direct from protocol direct 
set policy-options policy-statement send-direct then accept 

set routing-options router-id 192.0.2.5 

set routing-options autonomous-system 3 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide. 


To configure OSPFv2 sham links on each PE device: 


1. Configure the interfaces, including two loopback interfaces. 


[edit interfaces] 

user@PE1# set fe-1/2/0 unit O family inet address 10.1.1.2/30 
user@PE1# set fe-1/2/0 unit 0 family mpls 

user@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30 
user@PE1# set fe-1/2/1 unit 0 family mpls 

user@PE1# set loO unit O family inet address 192.0.2.2/24 
user@PE1# set loO unit 1 family inet address 198.51.100.2/24 


2. Configure MPLS on the core-facing interface. 


[edit protocols mpls] 
user@PE1# set interface fe-1/2/1.0 
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3. Configure internal BGP (IBGP). 


[edit ] 

user@PE1# set protocols bgp group toR4 type internal 
user@PE1# set protocols bgp group toR4 local-address 192.0.2.2 
user@PE1# set protocols bgp group toR4 family inet-vpn unicast 
user@PE1# set protocols bgp group toR4 neighbor 192.0.2.4 


4. Configure OSPF on the core-facing interface and on the loopback interface that is being used in the 
main instance. 


[edit protocols ospf area 0.0.0.0] 
user@PE1# set interface fe-1/2/1.0 
user@PE1# set interface lo0.0 passive 


5. Configure LDP or RSVP on the core-facing interface and on the loopback interface that is being used 
in the main instance. 


[edit protocols Idp] 
user@PE1# set interface fe-1/2/1.0 
user@PE1# set interface lo0.0 


6. Configure a routing policy for use in the routing instance. 


[edit policy-options policy-statement bgp-to-ospf] 
user@PE1# set term 1 from protocol bgp 
user@PE1# set term 1 then accept 

user@PE1# set term 2 then reject 


7. Configure the routing instance. 


[edit routing-instances red] 

user@PE1# set instance-type vrf 

user@PE1# set interface fe-1/2/0.0 

user@PE1# set route-distinguisher 2:1 

user@PE1# set vrf-target target:2:1 

user@PE1# set protocols ospf export bgp-to-ospf 

user@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 


8. Configure the OSPFv2 sham link. 
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Include the extra loopback interface in the routing instance and also in the OSPF configuration. 


Notice that the metric on the sham-link interface is set to 10. On Device CE1’s backup OSPF link, the 
metric is set to 100. This causes the sham link to be the preferred link. 


[edit routing-instances red] 

user@PE1# set interface lo0.1 

user@PE1# set protocols ospf sham-link local 198.51.100.2 

user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 
user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1 


9. Configure the autonomous system (AS) number and the router ID. 


[edit routing-options] 
user@PE1# set router-id 192.0.2.2 
user@PE1# set autonomous-system 2 


10. If you are done configuring the device, commit the configuration. 


[edit] 
user@R1# commit 


Results 

Confirm your configuration by entering the show interfaces and the show routing-instances commands. 
If the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


Output for PE1: 


user@PE1# show interfaces 
fe-1/2/0 { 
unit Of 
family inet { 
address 10.1.1.2/30; 
} 


family mpls; 


} 
fe-1/2/1 { 
unit O { 
family inet { 
address 10.1.1.5/30; 


} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 192.0.2.2/24, 


} 
unit 1 { 
family inet { 
address 198.51.100.2/24, 


user@PE1# show protocols 
mpls { 
interface fe-1/2/1.0,; 
} 
bgp { 
group toR4 { 
type internal; 
local-address 192.0.2.2; 
family inet-vpn { 
unicast; 
} 
neighbor 192.0.2.4; 


} 
ospf { 
area 0.0.0.0 { 
interface fe-1/2/1.0; 
interface 100.0 { 
passive; 


} 

Idp { 
interface fe-1/2/1.0; 
interface 100.0; 
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user@PE1# show policy-options 
policy-statement bgp-to-ospf { 
term 1 { 
from protocol bgp; 
then accept; 
} 
term 2 { 
then reject; 


user@PE1# show routing-instances 
red { 
instance-type vrf; 
interface fe-1/2/0.0; 
interface 100.1; 
route-distinguisher 2:1; 
vrf-target target:2:1; 
protocols { 
ospf { 
export bgp-to-ospf; 
sham-link local 198.51.100.2; 
area 0.0.0.0 { 
sham-link-remote 198.51.100.4 metric 10; 
interface fe-1/2/0.0; 
interface 100.1; 


user@PE1# show routing-options 
router-id 192.0.2.2; 


autonomous-system 2; 


Verification 


IN THIS SECTION 


@ Verifying the Sham Link Interfaces | 552 
@ Verifying the Local and Remote End Points of the Sham Link | 552 


551 


@ ~~ Verifying the Sham Link Adjacencies | 553 
@ Verifying the Link-State Advertisement | 553 
@ Verifying the Path Selection | 554 


Confirm that the configuration is working properly. 


Verifying the Sham Link Interfaces 


Purpose 

Verify the sham link interface. The sham link is treated as an interface in OSPFv2, with the named displayed 
as shamlink.<unique identifier>, where the unique identifier is a number. For example, shamlink.O. The 
sham link appears as a point-to-point interface. 


Action 


From operational mode, enter the show ospf interface instance instance-name command. 


user@PE1> show ospf interface instance red 





Interface State Area DR ID BDR ID Nbrs 
LOO) 5 DR OPLORORO 19@ 51, 100.2 ORL ORIORn0) 
0 
fe-1/2/0.0 Betore O.0.0.0 ORO RORO) OOOO 
shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 


Verifying the Local and Remote End Points of the Sham Link 


Purpose 
Verify the local and remote end points of the sham link. The MTU for the sham link interface is always 
zero. 


Action 
From operational mode, enter the show ospf interface instance instance-name detail command. 


user@PE1> show ospf interface shamlink.0O instance red 





Interface State Area DR ID BDR ID Nbrs 
shamlink.0 Peterc O0.0.0 CORIO RO RO) CORIO RONG) AL 
lyoeSs RAP, Mccessss W000, Masks @.0.0.0, Mawes OW, Cosicgs 10 
Local: 196.51,.100.2, Remote: 199.51.100.4 
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Adj count: 1 

Hello: 10, Dead: 40, RexXmit: 5, Not Stub 
Auth type: None 

Protection typ None, No eligible backup 





nosxollochy cleiewihe (1D ©) —S Cosicg 0 


Verifying the Sham Link Adjacencies 


Purpose 


Verify the adjacencies between the configured sham links. 


Action 


From operational mode, enter the show ospf neighbor instance instance-name command. 





user@PE1> show ospf neighbor instance red 


Address Interface State atiD) Pri Dead 

AO) 5 beg al, ak re=1/2/0.0 Full 192. 0o251 128 5) 

193,51. 100.4 shamlink.0 Full 19, Sil 100.4 0 
Sul 


Verifying the Link-State Advertisement 


Purpose 


Verify that the router LSA originated by the instance carries the sham link adjacency as an unnumbered 


point-to-point link. The link data for sham links is anumber ranging from Ox80010000 through Ox8001ffff. 


Action 


From operational mode, enter the show ospf database instance instance-name command. 


user@PE1> show ospf database instance red 





OSPF database, Area 0.0.0.0 
Type ID Cksum Len 
Router U2 oOo Bo dt 
Router M2 0 os 


Nomicere “ile Sil, LOO, 2 


Adv Rtr seq Age Opt 
192,052.51 0x80000009 1803 0x22 Ox6ec7 72 
192 50.255 0x80000007 TO Ws22 Wee Wz 

198.51, 10052 0x80000006 55 0x22 Oxda6b 





60 

Router LDS 551k 5 LOO. 4! ALN} 4 Sul. 5 LOO), 4 0x80000005 (36 nn Ob. © Oboe) 
60 

Network 10.0.0.18 IZ 6052.5 0x80000002 FO O22 Oeewi 32 
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OSPF AS SCOPE link state database 








Type ID Adv Rtr Seq Age Opt Cksum Len 
Extern 193,51 ,.100.,2 193, 51,100.54 0x80000002 72 Oxa2 0x343 
36 
Extern *198.51.100.4 193 51,100 52 0x80000002 71 Oxa2 0xe263 
36 


Verifying the Path Selection 


Purpose 
Verify that the Layer 3 VPN path is used instead of the backup path. 


Action 


From operational mode, enter the traceroute command from Device CE1 to Device CE2. 





user@CE1> traceroute 192.0.2.5 


traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets 
to dOelot.2 (10,0.1.2) 1.930 ms 1.664 ms 1.643 ms 
Qe aS ee 
3 IO.t.1.10 (O.1,1,10) 2.485 ms 1.4355 ms 1.422 ms 
MPLS Label=299808 CoS=0 TTL=1 S=1 
A i192.0,.2,.5 (192.0.2.5) 1.347 ms 1.562 ms 1.329 ms 





Meaning 


The traceroute operation shows that the Layer 3 VPN is the preferred path. If you were to remove the 


sham link or if you were to modify the OSPF metric to prefer that backup path, the traceroute would show 
that the backup path is preferred. 


RELATED DOCUMENTATION 


Day One: Advanced OSPF in the Enterprise 
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Configuring OSPF on Logical Systems 


IN THIS SECTION 


@ OSPF Support for Logical Systems | 556 


@ Example: Configuring OSPF on Logical Systems Within the Same Router | 557 


| OSPF Support for Logical Systems 


IN THIS SECTION 


@ Introduction to Logical Systems | 556 
@ ~~ OSPF and Logical Systems | 556 


This topic describes the following information: 


Introduction to Logical Systems 


With Junos OS, you can partition a single physical router into multiple logical devices that perform 
independent routing tasks. Because logical systems perform a subset of the tasks once handled by the 
main router, logical systems offer an effective way to maximize the use of a single routing or switching 
platform. Logical systems have their own unique routing tables, interfaces, policies, and routing instances. 


OSPF and Logical Systems 


You can configure both OSPF Version 2 (OSPFv2) and OSPF Version 3 (OSPF v3) for logical systems. In 
the case of OSPF v3, you can also configure OSPFv3 realms for logical systems, which allows OSPFv3 to 
advertise address families other than unicast IPvé6. 
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You configure OSPF for logical systems at the following hierarchy levels: 


e [edit logical-systems logical-system-name protocols (ospf | ospf3)] 


e [edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | 
ipv6-multicast)] 


e [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | 
ospf3)] 


e [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm 
(ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Example: Configuring OSPF on Logical Systems Within the Same Router 


IN THIS SECTION 


Requirements | 557 
Overview | 557 
Configuration | 558 


Verification | 563 


This example shows how to configure an OSPF network using multiple logical systems that are running 
on a single physical router. The logical systems are connected by logical tunnel interfaces. 


Requirements 


You must connect the logical systems by using logical tunnel (It) interfaces. See Example: Connecting Logical 
Systems Within the Same Device Using Logical Tunnel Interfaces on MX Series Routers and EX Series Switches. 


Overview 


This example shows the configuration of a single OSPF area with three logical systems running on one 
physical router. Each logical system has its own routing table. The configuration enables the protocol on 
all logical system interfaces that participate in the OSPF domain and specifies the area that the interfaces 


are in. 


Figure 32 on page 558 shows the sample network. 
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Figure 32: OSPF on Logical Systems 






Router 1 


Area 0.0.0.0 


It-1/2/0.0 
10.0.1.2 


It-1/2/0.2 
10.0.0.1 It-1/2/0.5 
10.0.1.1 


It-1/2/0.3 
10.0.2.1 


It-1/2/0.1 
10.0.0.2 


It-1/2/0.4 
10.0.2.2 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


set logical-systems LS1 interfaces It-1/2/0 unit 0 description LS1->LS3 

set logical-systems LS1 interfaces It-1/2/0 unit 0 encapsulation ethernet 

set logical-systems LS1 interfaces It-1/2/0 unit 0 peer-unit 5 

set logical-systems LS1 interfaces It-1/2/0 unit 0 family inet address 10.0.1.2/30 
set logical-systems LS1 interfaces It-1/2/0 unit 2 description LS1->LS2 

set logical-systems LS1 interfaces It-1/2/0 unit 2 encapsulation ethernet 

set logical-systems LS1 interfaces It-1/2/0 unit 2 peer-unit 1 

set logical-systems LS1 interfaces It-1/2/0 unit 2 family inet address 10.0.0.1/30 
set logical-systems LS1 protocols ospf area 0.0.0.0 interface It-1/2/0.0 

set logical-systems LS1 protocols ospf area 0.0.0.0 interface It-1/2/0.2 

set logical-systems LS2 interfaces It-1/2/0 unit 1 description LS2->LS1 

set logical-systems LS2 interfaces It-1/2/0 unit 1 encapsulation ethernet 

set logical-systems LS2 interfaces It-1/2/0 unit 1 peer-unit 2 

set logical-systems LS2 interfaces It-1/2/0 unit 1 family inet address 10.0.0.2/30 
set logical-systems LS2 interfaces It-1/2/0 unit 4 description LS2->LS3 
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set logical-systems LS2 interfaces It-1/2/0 unit 4 encapsulation ethernet 

set logical-systems LS2 interfaces It-1/2/0 unit 4 peer-unit 3 

set logical-systems LS2 interfaces It-1/2/0 unit 4 family inet address 10.0.2.2/30 
set logical-systems LS2 protocols ospf area 0.0.0.0 interface It-1/2/0.1 

set logical-systems LS2 protocols ospf area 0.0.0.0 interface It-1/2/0.4 

set logical-systems LS3 interfaces It-1/2/0 unit 3 description LS3->LS2 

set logical-systems LS3 interfaces It-1/2/0 unit 3 encapsulation ethernet 

set logical-systems LS3 interfaces It-1/2/0 unit 3 peer-unit 4 

set logical-systems LS3 interfaces It-1/2/0 unit 3 family inet address 10.0.2.1/30 
set logical-systems LS3 interfaces It-1/2/0 unit 5 description LS3->LS1 

set logical-systems LS3 interfaces It-1/2/0 unit 5 encapsulation ethernet 

set logical-systems LS3 interfaces It-1/2/0 unit 5 peer-unit O 

set logical-systems LS3 interfaces It-1/2/0 unit 5 family inet address 10.0.1.1/30 
set logical-systems LS3 protocols ospf area 0.0.0.0 interface It-1/2/0.5 

set logical-systems LS3 protocols ospf area 0.0.0.0 interface It-1/2/0.3 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure OSPF on logical systems: 


1. Configure the logical tunnel interface on Logical System LS1 connecting to Logical System LS2. 


[edit] 

user@host# set logical-systems LS1 interfaces It-1/2/0 unit 2 description LS1->LS2 
user@host# set logical-systems LS1 interfaces It-1/2/0 unit 2 encapsulation ethernet 
user@host# set logical-systems LS1 interfaces It-1/2/0 unit 2 peer-unit 1 

user@host# set logical-systems LS1 interfaces It-1/2/0 unit 2 family inet address 10.0.0.1/30 


2. Configure the logical tunnel interface on Logical System LS1 connecting to Logical System LS3. 


[edit] 

user@host# set logical-systems LS1 interfaces It-1/2/0 unit 0 description LS1->LS3 
user@host# set logical-systems LS1 interfaces It-1/2/0 unit 0 encapsulation ethernet 
user@host# set logical-systems LS1 interfaces It-1/2/0 unit 0 peer-unit 5 

user@host# set logical-systems LS1 interfaces It-1/2/0 unit 0 family inet address 10.0.1.2/30 


3. Configure the logical tunnel interface on Logical System LS2 connecting to Logical System LS1. 


[edit] 
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user@host# set logical-systems LS2 interfaces It-1/2/0 unit 1 description LS2->LS1 
user@host# set logical-systems LS2 interfaces It-1/2/0 unit 1 encapsulation ethernet 
user@host# set logical-systems LS2 interfaces It-1/2/0 unit 1 peer-unit 2 

user@host# set logical-systems LS2 interfaces It-1/2/0 unit 1 family inet address 10.0.0.2/30 


4. Configure the logical tunnel interface on Logical System LS2 connecting to Logical System LS3. 


[edit] 

user@host# set logical-systems LS2 interfaces It-1/2/0 unit 4 description LS2->LS3 
user@host# set logical-systems LS2 interfaces It-1/2/0 unit 4 encapsulation ethernet 
user@host# set logical-systems LS2 interfaces It-1/2/0 unit 4 peer-unit 3 

user@host# set logical-systems LS2 interfaces It-1/2/0 unit 4 family inet address 10.0.2.2/30 


5. Configure the logical tunnel interface on Logical System LS3 connecting to Logical System LS2. 


[edit] 

user@host# set logical-systems LS3 interfaces It-1/2/0 unit 3 description LS3->LS2 
user@host# set logical-systems LS3 interfaces It-1/2/0 unit 3 encapsulation ethernet 
user@host# set logical-systems LS3 interfaces It-1/2/0 unit 3 peer-unit 4 

user@host# set logical-systems LS3 interfaces It-1/2/0 unit 3 family inet address 10.0.2.1/30 


6. Configure the logical tunnel interface on Logical System LS3 connecting to Logical System LS1. 


[edit] 

user@host# set logical-systems LS3 interfaces It-1/2/0 unit 5 description LS3->LS1 
user@host# set logical-systems LS3 interfaces It-1/2/0 unit 5 encapsulation ethernet 
user@host# set logical-systems LS3 interfaces It-1/2/0 unit 5 peer-unit 0 

user@host# set logical-systems LS3 interfaces It-1/2/0 unit 5 family inet address 10.0.1.1/30 


7. Configure OSPF on all the interfaces. 


[edit] 

user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface It-1/2/0.0 
user@host# set logical-systems LS1 protocols ospf area 0.0.0.0 interface It-1/2/0.2 
user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface It-1/2/0.1 
user@host# set logical-systems LS2 protocols ospf area 0.0.0.0 interface It-1/2/0.4 
user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface It-1/2/0.5 
user@host# set logical-systems LS3 protocols ospf area 0.0.0.0 interface It-1/2/0.3 


8. If you are done configuring the device, commit the configuration. 


[edit] 
user@host# commit 


Results 


Confirm your configuration by issuing the show logical-systems command. 


show logical-systems 
LS1{ 
interfaces { 
It-1/2/0 { 
unit O { 
description LS1->LS3; 
encapsulation ethernet; 
peer-unit 5; 
family inet { 
address 10.0.1.2/30; 


} 
unit 2 { 
description LS1->LS2; 
encapsulation ethernet; 
peer-unit 1; 
family inet { 
address 10.0.0.1/30; 


} 
protocols { 
ospf { 
area 0.0.0.0 { 
interface It-1/2/0.0; 
interface It-1/2/0.2; 


} 
LS2 { 
interfaces { 
It-1/2/0 { 
unit 1 { 
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description LS2->LS1; 
encapsulation ethernet; 
peer-unit 2; 
family inet { 

address 10.0.0.2/30; 


} 
unit 4 { 
description LS2->LS3; 
encapsulation ethernet; 
peer-unit 3; 
family inet { 
address 10.0.2.2/30; 


} 
protocols { 
ospf { 
area 0.0.0.0 { 
interface It-1/2/0.1; 
interface It-1/2/0.4; 


} 
LS3 { 
interfaces { 
It-1/2/0 { 
unit 3 { 
description LS3->LS2; 
encapsulation ethernet; 
peer-unit 4; 
family inet { 
address 10.0.2.1/30; 


} 
unit 5 { 
description LS3->LS1; 
encapsulation ethernet; 
peer-unit O; 
family inet { 
address 10.0.1.1/30; 
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} 
protocols { 
ospf { 
area 0.0.0.0 { 
interface It-1/2/0.5; 
interface It-1/2/0.3; 


Verification 


IN THIS SECTION 


@ Verifying That the Logical Systems Are Up | 563 


@ Verifying Connectivity Between the Logical Systems | 564 


Confirm that the configuration is working properly. 


Verifying That the Logical Systems Are Up 


Purpose 


Make sure that the interfaces are properly configured. 
Action 


user@host> show interfaces terse 


Interface Admin Link Proto Local 
Lie 1/20 up up 

eH /2/0).0 up up inet LO 0. 
He=1/2/'0 . iL up up inet HOOF 
e=1/2/0 .2 up up inet 10.0. 
Nel /2/0.3 up up inet LOO. 
Le=1/2/0 4 up up inet LOO. 











Isr Iss) ey ~S) | 


750) 
730) 
ol / 30 
olf 30 
727/30) 


Remote 
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e=1/2/0 5 up up inet 10.0.1 ,1/30 


Verifying Connectivity Between the Logical Systems 


Purpose 


Make sure that the OSPF adjacencies are established by checking the OSPF neighbor tables, checking the 
routing tables, and pinging the logical systems. 


Action 


user@host> show ospf neighbor logical-system LS1 


Address Interface State ID Pri Dead 
10.0.4. i Lic=1/2/0.0 ayo AL 10.0514 eS 37 
lO PROPS Ope2 We =1/2/0 2 Full OPO Ole 128 33) 


user@host> show ospf neighbor logical-system LS2 


Address Interface State IED) Pri Dead 
LO PROPS Opes e=1/2/0. i Full 10,050. a 128 32 
10-0) 52 ¢ i hie /2/ 0.4 Full 10.0.0. i 128 36 


user@host> show ospf neighbor logical-system LS3 


Address Interface State ID Pri Dead 
10.0 5252 Le=il/2/0>3 iw JL LO.0.0.2 128 36 
10.0 1.2 LeHil/f2/0.8 teu dL 10.0505 i 128 37 


user@host> show route logical-system LS1 


inet.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 
OP OM OROnesi0) *(Direct/0] 00:28:00 

= wite heal / 2/0. 2 
10.0.0,1/32 local sO MOOR 285100 


MO Gaul velh alate —sle/ 029/02 


hOPLOrp ln OVes0) *[Direct/0] 00:28:00 
S wie de-1/2/0.0 
19 0,1.2/32 “(LOCAL / Ol OOS2Ss0C 
Local wala le-1/2/0.0 
10 .0.2.0/ 30 OSE E/AROs MOOK 2y/ 0S) meme teres me 
2S ico LO,0 1,1 wie ke-l/2/0.0 
66 10,0,0.2 wie Ie-i1/2/0,2 
LE 0,0, 5/32 PALOSEH/ AOS me OOke2.0r10)S7 men cierano mel 
MultiRecv 





user@host> show route logical-system LS2 


inet.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 











+ = Active Route, Last Active, * = Both 
MORON O01 3:0 2 ([Diakiasreic /0)|| WOg7isi3 Sal 
2 wile lie-1/2/0.0 
10.0.0.2/32 a \feesul/O]) OW s 283 s.2 
Local wila le=i1/2/0.1 
10 ,.0,1.,0/30 “(OSD /10]| OVE2Z7Is38, were 2 


Sto 10,0001 waa le-1/2/0.1 
~tOG 10,0,2.1 wie We-1/2/0,4 


10 .0.2.0/30 “(Direct / 0] MMs 2232 
an as a ol OE 
IO .0 2.28732 A Local/ Ol) C0282 32 
Local via 1t-1/2/0.4 
228 0.0. 5/32 “(OSDr/10]| OVE25ssa, weenie I 
MultiRecv 


user@host> show route logical-system LS3 


inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


LO POR OM ON/ec.0) =OS27/ 10 ]| WOe29823, metre 2 
Sco 10,0.2.2 wie Ie=-1/2/0.3 
tO LO,0,1,2 wie he=1/2/0.5 


MOP OR ea OV/iS10 *[Direct/0] 00:29:13 
> wile le-1/2/0.5 
1O.Msl 1/32 =[Lecal/O]| OWs293 15 


hocall vala We=1/270.5 
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10.0.2 .0/ 30 


10, 0,2,1/ 32 


22 GEOR Ono SZ 


From LS1, Ping LS3 


*(Direct/ 0] O00: 29714 
S wie de-1l/2/0.S 
=| Ieee 10 || les 2S)s 15 
Local wie Le-1/2/0.3 
[OSE Hy ARO} MOO Or BlGr meme iteraano mal 
MultiRecv 


user@host> set cli logical-system LS1 


user@host:LS1> ping 10.0.2.1 


PANG ROR Or Zeel 
64 bytes from 
64 bytes from 
64 bytes from 


From LS3, Ping LS1 


GHOR OR 2) i ocmcatamboyiees 

10.0.2.1: icmp_seq=0 tt1=64 time=1.215 ms 
10.0.2.1: icmp_seq=1 tt1=64 time=1.150 ms 
10.0.2.1: icmp_seq=2 tt1=64 time=1.134 ms 











user@host> set cli logical-system LS3 


user@host:LS3> ping 10.0.0.1 


Pau CeO ROO eel! 
64 bytes from 
64 bytes from 
64 bytes from 


GOR OR ORS) seo Gmcaitamoyiees 

10.0.0.1: icmp_seq=0 tt1=64 time=1.193 ms 
10.0.0.1: icmp_seq=1 tt1=64 time=1.114 ms 
10.0.0.1: icmp_seq=2 tt1=64 time=1.190 ms 
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| Working with Problems on Your Network 


Problem 


Description: This checklist provides links to troubleshooting basics, an example network, and includes a 
summary of the commands you might use to diagnose problems with the router and network. 


Solution 


Table 4: Checklist for Working with Problems on Your Network 


Tasks 


Command or Action 


“Isolating a Broken Network Connection” on page 569 


1. 


2. 


Identifying the Symptoms of a Broken Network Connection | ping (ip-address | hostname) 
on page 570 show route (ip-address | hostname) 
traceroute (ip-address | hostname) 
Isolating the Causes of a Network Problem on page 572 show < configuration | interfaces | protocols | route 


> 
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Table 4: Checklist for Working with Problems on Your Network (continued) 


Tasks Command or Action 
3. Taking Appropriate Action for Resolving the Network [edit] 
Problem on page 573 delete routing options static route destination-prefix 


commit and-quit 
show route destination-prefix 


4. Evaluating the Solution to Check Whether the Network show route (ip-address | hostname) 


Problem Is Resolved on page 574 ping (ip-address | hostname) count 3 
traceroute (ip-address | hostname) 


| Isolating a Broken Network Connection 


By applying the standard four-step process illustrated in Figure 33 on page 569, you can isolate a failed 
node in the network. Note that the functionality described in this section is not supported in versions 
15.1X49, 15.1X49-D30, or 15.1X49-D40. 


Figure 33: Process for Diagnosing Problems in Your Network 














Identify , Evaluate | Solved S 
|_| Isolate causes |} | Take action || . tL ———p} Done 
the symptom the solution = 


i t t Y Natsved 


Before you embark on the four-step process, however, it is important that you are prepared for the 
inevitable problems that occur on all networks. While you might find a solution to a problem by simply 
trying a variety of actions, you can reach an appropriate solution more quickly if you are systematic in your 
approach to the maintenance and monitoring of your network. To prepare for problems on your network, 
understand how the network functions under normal conditions, have records of baseline network activity, 















































and carefully observe the behavior of your network during a problem situation. 


Figure 34 on page 570 shows the network topology used in this topic to illustrate the process of diagnosing 
problems in a network. 
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Figure 34: Network with a Problem 
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Key: 
so-0/0/X: 10.1.x.x/30 
lo0: 10.0.0.x/32 





The network in Figure 34 on page 570 consists of two autonomous systems (ASs). AS 65001 includes two 
routers, and AS 65002 includes three routers. The border router (R1) in AS 65001 announces aggregated 
prefixes 100.100/24 to the AS 65002 network. The problem in this network is that R6 does not have 
access to R5 because of a loop between R2 and Ré. 


To isolate a failed connection in your network, follow the steps in these topics: 


e Isolating the Causes of a Network Problem on page 572 
e Taking Appropriate Action for Resolving the Network Problem on page 573 
e Taking Appropriate Action for Resolving the Network Problem on page 573 


e Evaluating the Solution to Check Whether the Network Problem Is Resolved on page 574 


| Identifying the Symptoms of a Broken Network Connection 


Problem 


Description: The symptoms of a problem in your network are usually quite obvious, such as the failure to 
reach a remote host. 


Solution 
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To identify the symptoms of a problem on your network, start at one end of your network and follow the 
routes to the other end, entering all or one of the following Junos OS command-line interfaces (CLI) 
operational mode commands: 


user@host> ping (ip-address | host-name) 
user@host> show route (ip-address | host-name) 
user@host> traceroute (ip-address | host-name) 


Sample Output 


user@R6> ping 10.0.0.5 
Daun GoelkOR Oe Or roun GhOOROP >) en olOmcealncmloyines 
36 bytes from 10.1.26.1: Time to live exceeded 
Wag 15, “ONS — IkvSsint 1D) WILG; OIE Wilh Peo CKS sre Dsis 
4 5 00 0054 e2db 0 ©©O@ OL OL asee 10.1.26,.2 10.0.0.5 


36 bytes from 10.1.26.1: Time to live exceeded 
Woe Jsllk; WOS Issn 1D) Wiley Oi UU PRO Ck ee! Dsic 
4 5 00 0054 e2de 09 OOO“ OL Ol ages IO1.256,2 10.,0,0.5 


36 bytes from 10.1.26.1: Time to live exceeded 
Wie 1sUL; WO; —IySsiat LD) Wile OL UU PrQ Ck Sue! Ds 

4 5 00 0054 e2e2 0 O©OOC OL OL alot 1O.1-26,.2 10.0.0.5 
AG 


=== 10.0,0.5 joimgy Statistics === 


3 packets transmitted, 0 packets received, 100% packet loss 


user@R6> show route 10.0.0.5 


inet.0: 20 destinations, 20 routes (20 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


10 .60.0.5/32 “[IS-1S/165] OOsO2s39, metre 10 
> to 10.1.26.1 via so-0/0/2.0 


user@R6> traceroute 10.0.0.5 


traceroute to 10.0.0.5 (10.0.0.5), 30 hops max, 40 byte packets 
L IO.1.26,1 (LO51.26.1) ©.649 ms O.521 ms 0,490 ms 
2 01.2658 (l0,1,.26-2) ©.521 ms O.537 ms 0.507 me 
3 IO.1.26,1 (10,1,26.1) 0.523 ms 0.536 ms 0.514 ms 
A AO 1.26.2 (101,260.52) 0.528 ms 0.551 ms 0.525 ms 
S IO.1,.26,1 (10,1,.26.1) O.531 ms 0.550 ms 0.524 ms 
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Meaning 


The sample output shows an unsuccessful ping command in which the packets are being rejected because 
the time to live is exceeded. The output for the show route command shows the interface (10.1.26.1) that 
you can examine further for possible problems. The traceroute command shows the loop between 10.1.26.1 
(R2) and 10.1.26.2 (R6), as indicated by the continuous repetition of the two interface addresses. 


Isolating the Causes of a Network Problem 


Problem 
Description: A particular symptom can be the result of one or more causes. Narrow down the focus of 
your search to find each individual cause of the unwanted behavior. 


Solution 
To isolate the cause of a particular problem, enter one or all of the following Junos OS CLI operational 
mode command: 


user@host> show < configuration | bgp | interfaces | isis | ospf | route > 


Your particular problem may require the use of more than just the commands listed above. See the 
appropriate command reference for a more exhaustive list of commonly used operational mode commands. 


Sample Output 


user@R6> show interfaces terse 


Interface Admin Link Proto Local Remote 
so-0/0/0 up up 
so-0/0/0.0 up up inet 10.1.56.2/30 
iso 
so-0/0/2 up up 
so-0/0/2.0 up up ime 10,1,26.2/30 
iso 
so-0/0/3 up up 
so-0/0/3.0 up up Tere to OP lS 16 2127/7310 
iso 


lsc OWEN cei AceCl. . .] 


The following sample output is from R2: 


user@R2> show route 10.0.0.5 
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inet.0: 22 destinations, 25 routes (22 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


10.0,.0,5/32 *[Static/5] 00:16:21 
> to 10.1.26.2 via so-0/0/2.0 
[SGP ON Sa 520328 357) MEDS >, localoret L010 
MS jOsiclag SOOL 1 
> tO 10,1,12.1 wie so-0/0/0.0 





Meaning 


The sample output shows that all interfaces on R6 are up. The output from R2 shows that a static route 
[Static/5] configured on R2 points to R6 (10.1.26.2) and is the preferred route to R5 because of its low 
preference value. However, the route is looping from R2 to R6, as indicated by the missing reference to 
R5 (10.1.15.2). 


Taking Appropriate Action for Resolving the Network Problem 


Problem 

Description: The appropriate action depends on the type of problem you have isolated. In this example, 
a static route configured on R2 is deleted from the [routing-options] hierarchy level. Other appropriate 
actions might include the following: 


Solution 

e Check the local router’s configuration and edit it if appropriate. 
e Troubleshoot the intermediate router. 

e Check the remote host configuration and edit it if appropriate. 
e Troubleshoot routing protocols. 


e Identify additional possible causes. 


To resolve the problem in this example, enter the following Junos OS CLI commands: 


[edit] 

user@R2# delete routing-options static route destination-prefix 
user@R2# commit and-quit 

user@R2# show route destination-prefix 
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Sample Output 


[edit] 
user@R2# delete routing-options static route 10.0.0.5/32 


[edit] 
user@R2# commit and-quit 


commit complete 





Exiting configuration mode 


user@R2> show route 10.0.0.5 


inet.0: 22 destinations, 24 routes (22 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 








10.0.0,5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100 
AS path: 65001 | 
> t© 1O,1,12.1 wie so-0/0/0.0 


Meaning 
The sample output shows the static route deleted from the [routing-options] hierarchy and the new 


configuration committed. The output for the show route command now shows the BGP route as the 
preferred route, as indicated by the asterisk (*). 


Evaluating the Solution to Check Whether the Network Problem Is Resolved 


Problem 

Description: If the problem is solved, you are finished. If the problem remains or a new problem is identified, 
start the process over again. 

You can address possible causes in any order. In relation to the network in “Isolating a Broken Network 
Connection” on page 569, we chose to work from the local router toward the remote router, but you might 
start at a different point, particularly if you have reason to believe that the problem is related to a known 
issue, such as a recent change in configuration. 


Solution 


To evaluate the solution, enter the following Junos OS CLI commands: 


user@host> show route (ip-address |host-name) 
user@host> ping (ip-address | host-name) 


575 


user@host> traceroute (ip-address | host-name) 


Sample Output 


user@R6> show route 10.0.0.5 


inet.0: 20 destinations, 20 routes (20 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 











10.0,0,5/32 *[BGP/170] 00:01:35, MED 5, localpref 100, from 10.0.0.2 
MS jOsiclag SOO I 
Sant Onl Onpl2 Cr lenvel cues O— 01/0020 


user@R6> ping 10.0.0.5 

PING 10.0.0.5 (10.0.0.5): 56 data bytes 

64 bytes from 10.0.0.5: icmp_seq=0 tt1l=253 time=0.866 ms 
64 bytes from 10.0.0.5: icmp_seq=1 tt1l=253 time=0.837 ms 
64 bytes from 10.0.0.5: icmp_seq=2 tt1l=253 time=0.796 ms 
NG 

=== 10.0.0.5 Pimg Statistics === 

3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.796/0.833/0.866/0.029 ms 


user@R6> traceroute 10.0.0.5 

traceroute to 10.0.0.5 (10.0.0.5), 30 hops max, 40 byte packets 
Lt d0.1.26,1 (10,1,26.1) 0.629 ms O.538 ms 0.497 ime 
2 IO L.12.1 GO,1T.12.1) O.5354 ms O.535 ms O50 mes 
3 1O.0.0.5 (10,0.0.5) O776 ms O.705 me O.672 ms 


Meaning 


The sample output shows that there is now a connection between Ré6 and R5. The show route command 
shows that the BGP route to R35 is preferred, as indicated by the asterisk (*). The ping command is successful 
and the traceroute command shows that the path from R6 to R5 is through R2 (10.1.26.1), and then 
through R1 (10.1.12.1). 


| Checklist for Tracking Error Conditions 


Problem 
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Description: Table 5 on page 576 provides links and commands for configuring routing protocol daemon 
tracing, Border Gateway Protocol (BGP), Intermediate System-to-Intermediate System (IS-IS) protocol, 
and Open Shortest Path First (OSPF) protocol tracing to diagnose error conditions. 


Solution 


Table 5: Checklist for Tracking Error Conditions 


Tasks Command or Action 


Configure Routing Protocol Process Tracing 


1. Configure Routing Protocol Process Tracing on page 578 [edit] 
edit routing-options traceoptions 
set file filename size size files number 
show 
commit 
run show log filename 


2. Configure Routing Protocol Tracing for a Specific Routing Protocol on page 581 [edit] 
edit protocol protocol-name traceoption 
set file filename size size files number 
show 
commit 
run show log filename 


3. Monitor Trace File Messages Written in Near-Real Time on page 583 monitor start filename 
4. Stop Trace File Monitoring on page 584 monitor stop filename 


Configure BGP-Specific Options 


1. Display Detailed BGP Protocol Information [edit] 
edit protocol bgp traceoptions 
set flag update detail 
show 
commit 
run show log filename 


2. Display Sent or Received BGP Packets [edit] 
edit protocol bgp traceoptions 
set flag update (send | receive) 
show 
commit 
run show log filename 


Table 5: Checklist for Tracking Error Conditions (continued) 


Tasks 


3. Diagnose BGP Session Establishment Problems 


Configure IS-IS-Specific Options 


1. Displaying Detailed !S-IS Protocol Information 


2. Displaying Sent or Received IS-IS Protocol Packets 


3. Analyzing IS-IS Link-State PDUs in Detail 


Configure OSPF-Specific Options 


1. Diagnose OSPF Session Establishment Problems 
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Command or Action 


[edit] 

edit protocol bgp 

set traceoptions flag open detail 
show 

commit 

run show log filename 


[edit] 

edit protocol isis traceoptions 
set flag hello detail 

show 

commit 

run show log filename 


[edit] 

edit protocols isis traceoptions 
set flag hello (send | receive) 
show 

commit 

run show log filename 


[edit] 

edit protocols isis traceoptions 
set flag Isp detail 

show 

commit 

run show log filename 


[edit] 

edit protocols ospf traceoptions 
set flag hello detail 

show 

commit 

run show log filename 


578 


Table 5: Checklist for Tracking Error Conditions (continued) 


Tasks Command or Action 


2. Analyze OSPF Link-State Advertisement Packets in Detail [edit] 
edit protocols ospf traceoptions 
set flag Isa update detail 
show 
commit 
run show log filename 


| Configure Routing Protocol Process Tracing 


Action 


To configure routing protocol process (rpd) tracing, follow these steps: 


1. In configuration mode, go to the following hierarchy level: 


[edit] 
user@host# edit routing-options traceoptions 


2. Configure the file, file size, number, and flags: 


[edit routing-options traceoptions] 

user@host# set file filename size size file number 
[edit routing-options traceoptions] 

user@host# set flag flag 


For example: 


[edit routing-options traceoptions] 

user@host# set file daemonlog size 10240 files 10 
[edit routing-options traceoptions] 

user@host# set flag general 


3. Verify the configuration: 
user@host# show 


For example: 
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[edit routing-options traceoptions] 
user@host# show 
file daemonlog size 10k files 10; 


flag general; 
4. Commit the configuration: 


user@host# commit 


NOTE: Some traceoptions flags generate an extensive amount of information. Tracing can also 
slow down the operation of routing protocols. Delete the traceoptions configuration if you no 


longer require it. 


1. View the contents of the file containing the detailed messages: 
user@host# run show log filename 
For example: 


[edit routing-options traceoptions] 

user@pro4-a# run show log daemonlog 

Sep 17 14:17:31 trace_on: Tracing to "/var/log/daemonlog" started 
Sep 17 14:17:31 Tracing flags enabled: general 

Sep 17 14:17:31 inet_routerid_notify: Router ID: 10.255.245.44 
Sep 17 14:17:31 inet_routerid_notify: No Router ID assigned 
Sep 17 14:17:31 Initializing LS! globals 

Sep 17 14:17:31 LSI initialization complete 

Sep 17 14:17:31 Initializing OSPF instances 

Sep 17 14:17:31 Reinitializing OSPFv2 instance master 

Sep 17 14:17:31 OSPFv2 instance master running 

[...Output truncated...] 


Meaning 
Table 6 on page 580 lists tracing flags and example output for Junos-supported routing protocol daemon 
tracing. 
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Table 6: Routing Protocol Daemon Tracing Flags 


Tracing 
Flag 


all 


general 


normal 


policy 


route 


state 


Description 


All operations 


Normal 
operations and 
routing table 
change 


Normal 
operations 


Policy 
operations and 
actions 


Routing table 
changes 


State 
transitions 


Example Output 


Not available. 


Not available. 


Not available. 


Nov 29 22:19:58 export: Dest 10.0.0.0 proto Static 

Nov 29 22:19:58 policy_match_qual_or: Qualifier proto Sense: O 
Nov 29 22:19:58 policy_match_qual_or: Qualifier proto Sense: O 
Nov 29 22:19:58 export: Dest 10.10.10.0 proto IS-IS 


Nov 29 22:23:59 

Nov 29 22:23:59 rtlist_walker_job: rt_list walk for RIB inet.0 started with 42 entries 
Nov 29 22:23:59 rt_flash_update_callback: flash KRT (inet.O) start 

Nov 29 22:23:59 rt_flash_update_callback: flash KRT (inet.0) done 

Nov 29 22:23:59 rtlist_walker_job: rt_list walk for inet.0 ended with 42 entries 

Nov 29 22:23:59 

Nov 29 22:23:59 KRT Request: send len 68 v14 seq O CHANGE route/user af 2 addr 
172.16.0.0 nhop-type unicast nhop 10.10.10.33 

Nov 29 22:23:59 KRT Request: send len 68 v14 seq O ADD route/user af 2 addr 172.17.0.0 
nhop-type unicast nhop 10.10.10.33 

Nov 29 22:23:59 KRT Request: send len 68 v14 seq O ADD route/user af 2 addr 10.149.3.0 
nhop-type unicast nhop 10.10.10.33 

Nov 29 22:24:19 trace_on: Tracing to "/var/log/rpdlog" started 

Nov 29 22:24:19 KRT Request: send len 68 v14 seq O DELETE route/user af 2 addr 
10.10.218.0 nhop-type unicast nhop 10.10.10.29 

Nov 29 22:24:19 RELEASE 10.10.218.0 255.255.255.0 gw 10.10.10.29,10.10.10.33 BGP 
pref 170/-101 metric so-1/1/0.0,so-1/1/1.0 <Release Delete Int Ext> as 65401 

Nov 29 22:24:19 KRT Request: send len 68 v14 seq O DELETE route/user af 2 addr 
172.18.0.0 nhop-type unicast nhop 10.10.10.33 


Not available. 
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Table 6: Routing Protocol Daemon Tracing Flags (continued) 


Tracing 
Flag Description Example Output 


task Interface Nov 29 22:50:04 foreground dispatch running job task_collect for task Scheduler 

transactions Nov 29 22:50:04 task_collect_job: freeing task MGMT_Listen (DELETED) 

and processing Nov 29 22:50:04 foreground dispatch completed job task_collect for task Scheduler 
Nov 29 22:50:04 background dispatch running job rt_static_update for task RT 
Nov 29 22:50:04 task_job_delete: delete background job rt_static_update for task RT 
Nov 29 22:50:04 background dispatch completed job rt_static_update for task RT 
Nov 29 22:50:04 background dispatch running job Flash update for task RT 
Nov 29 22:50:04 background dispatch returned job Flash update for task RT 
Nov 29 22:50:04 background dispatch running job Flash update for task RT 
Nov 29 22:50:04 task_job_delete: delete background job Flash update for task RT 
Nov 29 22:50:04 background dispatch completed job Flash update for task RT 
Nov 29 22:50:04 background dispatch running job Flash update for task RT 
Nov 29 22:50:04 task_job_delete: delete background job Flash update for task RT 


timer Timer usage Nov 29 22:52:07 task_timer_hiprio_dispatch: ran 1 timer 
Nov 29 22:52:07 main: running normal priority timer queue 
Nov 29 22:52:07 main: ran 1 timer 
Nov 29 22:52:07 task_timer_hiprio_dispatch: running high priority timer queue 
Nov 29 22:52:07 task_timer_hiprio_dispatch: ran 1 timer 
Nov 29 22:52:07 main: running normal priority timer queue 
Nov 29 22:52:07 main: ran 1 timer 
Nov 29 22:52:07 main: running normal priority timer queue 
Nov 29 22:52:07 main: ran 2 timers 


| Configure Routing Protocol Tracing for a Specific Routing Protocol 


Action 


To configure routing protocol tracing for a specific routing protocol, follow these steps: 


1. In configuration mode, go to the following hierarchy level: 


[edit] 
user@host# edit protocol protocol-name traceoptions 


2. Configure the file, file size, number, and flags: 


[edit protocols protocol name traceoptions] 
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user@host# set file filename size size files number 
[edit protocols protocol name traceoptions] 
user@host¢# set flag flag 


For example: 


[edit protocols ospf traceoptions] 

user@host¢# set file ospflog size 10240 files 10 
[edit protocols ospf traceoptions] 

user@host# set flag general 


3. Verify the configuration: 


user@host# show 


For example: 


[edit protocols ospf traceoptions] 
user@host# show 

file ospflog size 10k files 10; 

flag general; 


4. Commit the configuration: 


user@host# commit 


5. View the contents of the file containing the detailed messages: 


user@host# run show log filename 


For example: 


[edit protocols ospf traceoptions] 

user@pro4-a# run show log ospflog 

Sep 17 14:23:10 trace_on: Tracing to "/var/log/ospflog" started 

Sep 17 14:23:10 rt_flash_update_callback: flash OSPF (inet.O) start 

Sep 17 14:23:10 OSPF: multicast address 224.0.0.5/32, route ignored 

Sep 17 14:23:10 rt_flash_update_callback: flash OSPF (inet.0) done 

Sep 17 14:23:10 CHANGE 10.255.245.46/32 gw 10.10.208.67 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Delete 
Int> 

Sep 17 14:23:10 CHANGE 10.255.245.46/32 gw 10.10.208.67 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Active 
Int> 
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Sep 17 14:23:10 ADD 10.255.245.46/32 gw 10.10.208.67 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Active 
Int> 

Sep 17 14:23:10 CHANGE 10.255.245.48/32 gw 10.10.208.69 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Delete 
Int> 

Sep 17 14:23:10 CHANGE 10.255.245.48/32 gw 10.10.208.69 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Active 
Int> 

Sep 17 14:23:10 ADD 10.255.245.48/32 gw 10.10.208.69 OSPF pref 10/0 metric 1/0 fe-0/0/0.0 <Active 
Int> 

Sep 17 14:23:10 rt_close: 4/4 routes proto OSPF 

[...Output truncated...] 


Meaning 


Table 7 on page 583 lists standard tracing options that are available globally or that can be applied to 
specific protocols. You can also configure tracing for a specific BGP peer or peer group. For more 
information, see the Junos System Basics Configuration Guide. 


Table 7: Standard Trace Options for Routing Protocols 


Tracing Flag Description 


all All operations 

general Normal operations and routing table changes 
normal Normal operations 

policy Policy operations and actions 

route Routing table changes 

state State transitions 

task Interface transactions and processing 

timer Timer usage 


| Monitor Trace File Messages Written in Near-Real Time 


Purpose 


To monitor messages in near-real time as they are being written to a trace file. 


Action 


To monitor messages in near-real time as they are being written to a trace file, use the following Junos 


OS command-line interface (CLI) operational mode command: 


user@host> monitor start filename 


| Sample Output 


user@host> monitor start isis 


user@host> 
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| Stop Trace File Monitoring 


Action 


checksum Oxclc8, lifetime 1200 


To stop monitoring a trace file in near-real time, use the following Junos OS CLI operational mode command 


after you have started monitoring: 


user@host monitor stop filename 


Sample Output 


user@host> monitor start isis 
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user@host> 
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| Verifying an OSPF Configuration 


IN THIS SECTION 


Verifying OSPF-Enabled Interfaces | 587 
Verifying OSPF Neighbors | 588 
Verifying the Number of OSPF Routes | 589 


Verifying Reachability of All Hosts in an OSPF Network | 591 


To verify an OSPF configuration, perform these tasks: 


Verifying OSPF-Enabled Interfaces 


Purpose 
Verify that OSPF is running on a particular interface and that the interface is in the desired area. 


Action 


From the CLI, enter the show ospf interface command. 


| Sample Output 


user@host> show ospf interface 








Intf State Area DR 
aie=5,/ 1/00 Pie LORI ORO RaORG) O.0. 
ge-2/3/0.0 DR O.0.0.0 192 
HOORO DR O.0.0.0 RS ye 
so-0/0/0.0 Down OPORORO 0.0. 
SO Cy A0//alaO PtToPt OPFOR ORO 0.0 
SO a6) 0/20 Down 0.0.0.0 0.0 
SO 0/10/30 PETOPt OPLO POLO 0.0 
Meaning 


ID 

0.0 
168 
168 
0.0 


os Se S&S 
Ss Cc © 


-4.16 
-4.16 


BDR ID 








ee 
oS 2 2 4 


ORR 
toe 
ORF 


0.0 








a ee 
SS SS 6S 


168. 
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Nbrs 


4.15 


= S&S FP 2 & fF 


The output shows a list of the device interfaces that are configured for OSPF. Verify the following 


information: 


e Each interface on which OSPF is enabled is listed. 


e Under Area, each interface shows the area for which it was configured. 


e Under Intf and State, the device loopback (lo0.0) interface and LAN interface that are linked to the OSPF 


network's designated router (DR) are identified. 


e Under DR ID, the IP address of the OSPF network's designated router appears. 


e Under State, each interface shows a state of PtToPt to indicate a point-to-point connection. If the state 


is Waiting, check the output again after several seconds. A state of Down indicates a problem. 


e The designated router addresses always show a state of DR. 


Verifying OSPF Neighbors 


Purpose 


OSPF neighbors are interfaces that have an immediate adjacency. On a point-to-point connection between 


the device and another router running OSPF, verify that each router has a single OSPF neighbor. 


Action 


From the CLI, enter the show ospf neighbor command. 


Sample Output 


user@host> show ospf neighbor 


Address ILinieae State IID) 


IDA MGS 2545425 wos .0 2Way HO. 250.240", 32 


iDieaL 


128 


Dead 
36 
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192.168.254.230 fxp3.0 Full HOm2SOmeAl0me 128 38 

192.168.254.229 fxp3.0 Full 10, 250..240,, 35 128 33 

10,1, 1,129 fxp2.0 Full 1OR2505240n 12 128 37 

WW... 13a fxp2.0 Full 10, 250,240,110 128 38 

10.1.221 fxp1.0 Full 10.250.240.9 128 32 

Oct 2.8m fxp0.0 Full 10,250,240. 10 128 35 
Meaning 


The output shows a list of the device's OSPF neighbors and their addresses, interfaces, states, router IDs, 
priorities, and number of seconds allowed for inactivity (“dead” time). Verify the following information: 


e Each interface that is immediately adjacent to the device is listed. 


e The device's own loopback address and the loopback addresses of any routers with which the device 
has an immediate adjacency are listed. 


e Under State, each neighbor shows a state of Full. Because full OSPF connectivity is established over a 
series of packet exchanges between clients, the OSPF link might take several seconds to establish. During 
that time, the state might be displayed as Attempt, Init, or 2way, depending on the stage of negotiation. 


If, after 30 seconds, the state is not Full, the OSPF configuration between the neighbors is not functioning 
correctly. 


Verifying the Number of OSPF Routes 


Purpose 


Verify that the OSPF routing table has entries for the following: 
e Each subnetwork reachable through an OSPF link 
e Each loopback address reachable on the network 


For example, Figure 35 on page 590 shows a sample network with an OSPF topology. 
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Figure 35: Sample OSPF Network Topology 
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In this topology, OSPF is being run on all interfaces. Each segment in the network is identified by an address 
with a /24 prefix, with interfaces on either end of the segment being identified by unique IP addresses. 


Action 


From the CLI, enter the show ospf route command. 


Sample Output 


user@host> show ospf route 














Prefix Path Route NH Metric NextHop Nexthop 
Type Type Type Interface addr/label 

O10 510, 1/24 Intra Network I? 1 ge-0/0/2.0 LQ. 0.251 
O,10,10 2/724 Intra Network ie ll ge-0/0/2.0 10,0 ,21.1 
0.10.10.4/24 Intra Network in? al ge-0/0/1.0 LOG .0oL351 
OPO PaO ReSy a4 Intra Network IP 1 ge-0/0/2.0 10.0 .20. i 
OP eOR OMG 72.4 Intra Network IP 1 ge-0/0/1.0 1@.@.13,1 
OP LOR OR wOyi24 Intra Network I? al ge-0/0/2.0 LO .0.21.61 
O,10,10, i yp2e Intra Network IP 1 ge-0/0/1.0 IO .O0o135 1 
O.10,10., 13/24 Intra Network IP 1 ge-0/0/1.0 
OR OR ORGY i274 Intra Network I? il ge-0/0/1.0 IO 0.1351 
O10. 10.19/24 Intra Network ine al ge-0/0/1.0 ORO Pewlec tell 
O10, 10.20/24 Intra Network i? il ge-0/0/2.0 10.0, 2il., i 
19) LO, 10.21/24 Intra Network IP i ge-0/0/2.0 

192,168.51 Intra Router IP il ge-0/0/2.0 LOO .20, 1 
192 5168) 5552 Intra Router IP dl 100 

U2 4 WS 553) Intra Router IP il ge-0/0/1.0 KORO Reales Pall 
192,168.54 Intra Router IP 1 ge-0/0/1.0 AG .O.I1351 
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WED 4 WSS, S55) Intra Router 1 i ge-0/0/1.0 LQ .0cl351 
U2 9 MS 6 D5 G Intra Router ie als ge-0/0/2.0 105052161 
192, 168.5. 7 Intra Router IP il ge-0/0/2.0 10.021, i 
U2 MOS 6 S68 Intra Router Ie als ge-0/0/2.0 10,0521. i 
IY , 68.559 Intra Router It al ge-0/0/1.0 IO .O5136i 


Meaning 
The output lists each route, sorted by IP address. Routes are shown with a route type of Network, and 
loopback addresses are shown with a route type of Router. 


For the example shown in Figure 35 on page 590, verify that the OSPF routing table has 21 entries, one 
for each network segment and one for each router's loopback address. 


Verifying Reachability of All Hosts in an OSPF Network 


Purpose 


By using the traceroute tool on each loopback address in the network, verify that all hosts in the network 
are reachable from each device. 


Action 


For each device in the OSPF network: 


1. In the J-Web interface, select Troubleshoot>Traceroute. 


2. Inthe Host Name box, type the name of a host for which you want to verify reachability from the 
device. 


3. Click Start. Output appears on a separate page. 


| Sample Output 


1 172,17 40,254 C72. 17 40.254) O.362 ms O- 294 te O25 ims 
2 COMeSra—i5o0 —Gaglals imyocomoamy mee (LIZ L687 246) O.251 ms 0.255 me 0.200 ms 


Meaning 
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Each numbered row in the output indicates a routing “hop” in the path to the host. The three-time 
increments indicate the round-trip time (RTT) between the device and the hop, for each traceroute packet. 
To ensure that the OSPF network is healthy, verify the following information: 


e The final hop in the list is the host you want to reach. 


e The number of expected hops to the host matches the number of hops in the traceroute output. The 
appearance of more hops than expected in the output indicates that a network segment is likely not 
reachable. In this case, verify the routes with the show ospf route command. 


For information about show ospf route, see “Verifying the Number of OSPF Routes” on page 589 


Tracing OSPF Protocol Traffic 


Tracing operations record detailed messages about the operation of OSPF. You can trace OSPF protocol 
traffic to help debug OSPF protocol issues. When you trace OSPF protocol traffic, you specify the name 
of the file and the type of information you want to trace. 


You can specify the following OSPF protocol-specific trace options: 


e database-description—All database description packets, which are used in synchronizing the OSPF 
topological database 


error—OSPF error packets 


event—OSPF state transitions 


flooding—Link-state flooding packets 


graceful-restart—Graceful-restart events 


hello—Hello packets, which are used to establish neighbor adjacencies and to determine whether 
neighbors are reachable 


Idp-synchronization—Synchronization events between OSPF and LDP 


Isa-ack—Link-state acknowledgment packets, which are used in synchronizing the OSPF topological 


database 


Isa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of OSPF, Junos OS 


performs LSA analysis before running the shortest-path-first (SPF) algorithm. LSA analysis helps to speed 
the calculations performed by the SPF algorithm. 


Isa-request—Link-state request packets, which are used in synchronizing the OSPF topological database 


Isa-update—Link-state updates packets, which are used in synchronizing the OSPF topological database 


nsr-synchronization—Nonstop routing synchronization events 


e on-demand—Trace demand circuit extensions 
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packet-dump—Dump the contents of selected packet types 
packets—All OSPF packets 
restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events 


spf—Shortest path first (SPF) calculations 


You can optionally specify one or more of the following flag modifiers: 


detail—Detailed trace information 
receive—Packets being received 


send—Packets being transmitted 


NOTE: Use the detail flag modifier with caution as it might cause the CPU to become very busy. 


Global tracing options are inherited from the configuration set by the traceoptions statement at the [edit 


routing-options] hierarchy level. You can override the following global trace options for the OSPF protocol 


using the traceoptions flag statement included at the [edit protocols ospf] hierarchy level: 


all—All tracing operations 


general—All normal operations and routing table changes (a combination of the normal and route trace 
operations) 


normal—Normal events 

policy—Policy processing 
route—Routing information 
state—State transitions 

task—Routing protocol task processing 


timer—Routing protocol timer processing 


NOTE: Use the trace flag all with caution as it might cause the CPU to become very busy. 
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| Example: Tracing OSPF Protocol Traffic 


IN THIS SECTION 


Requirements | 594 
Overview | 594 
Configuration | 595 


Verification | 600 


This example shows how to trace OSPF protocol traffic. 


Requirements 


This example assumes that OSPF is properly configured and running in your network, and you want to 
trace OSPF protocol traffic for debugging purposes. 


Overview 


You can trace OSPF protocol traffic to help debug OSPF protocol issues. When you trace OSPF protocol 
traffic, you specify the name of the file and the type of information you want to trace. All files are placed 
in a directory on the routing device’s hard disk. On M Series and T Series routers, trace files are stored in 


the /var/log directory. 


This example shows a few configurations that might be useful when debugging OSPF protocol issues. The 
verification output displayed is specific to each configuration. 


TIP: To keep track of your log files, create a meaningful and descriptive name so it is easy to 
remember the content of the trace file. We recommend that you place global routing protocol 
tracing output in the file routing-log, and OSPF tracing output in the file ospf-log. 


In the first example, you globally enable tracing operations for all routing protocols that are actively running 
on your routing device to the file routing-log. With this configuration, you keep the default settings for 
the trace file size and the number of trace files. After enabling global tracing operations, you enable tracing 
operations to provide detailed information about OSPF packets, including link-state advertisements, 
requests, and updates, database description packets, and hello packets to the file ospf-log, and you configure 
the following options: 
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e size—Specifies the maximum size of each trace file, in KB, MB, or GB. In this example, you configure 10 
KB as the maximum size. When the file reaches its maximum size, it is renamed with a .O extension. 
When the file again reaches its maximum size, it is renamed with a .1 extension, and the newly created 
file is renamed with a .O extension. This renaming scheme continues until the maximum number of trace 
files is reached. Then, the oldest trace file is overwritten. If you specify a maximum file size, you must 
also specify a maximum number of trace files with the files option. You specify k for KB, m for MB, and 
g for GB. By default, the trace file size is 128 KB. The file size range is 10 KB through the maximum file 
size supported on your system. 


e files—Specifies the maximum number of trace files. In this example, you configure a maximum of 5 trace 
files. When a trace file reaches its maximum size, it is renamed with a .O extension, then a .1 extension, 
and so on until the maximum number of trace files is reached. When the maximum number of files is 
reached, the oldest trace file is overwritten. If you specify a maximum number of files, you must also 
specify a maximum file size with the size option. By default, there are 10 files. The range is 2 through 
1000 files. 


In the second example, you trace all SPF calculations to the file ospf-log by including the spf flag. You keep 
the default settings for the trace file size and the number of trace files. 


In the third example, you trace the creation, receipt, and retransmission of all LSAs to the file ospf-log by 
including the lsa-request, Isa-update, and Isa-ack flags. You keep the default settings for the trace file size 
and the number of trace files. 


Configuration 


IN THIS SECTION 


@ = Configuring Global Tracing Operations and Tracing OSPF Packet Information | 595 
@ Tracing SPF Calculations | 598 
@ ~~ Tracing Link-State Advertisements | 599 


Configuring Global Tracing Operations and Tracing OSPF Packet Information 


CLI Quick Configuration 


To quickly enable global tracing operations for all routing protocols actively running on your routing device 
and to trace detailed information about OSPF packets, copy the following commands and paste them into 
the CLI. 


[edit] 
set routing-options traceoptions file routing-log 


596 


set protocols ospf traceoptions file ospf-log 

set protocols ospf traceoptions file files 5 size 10k 

set protocols ospf traceoptions flag Isa-ack 

set protocols ospf traceoptions flag database-description 
set protocols ospf traceoptions flag hello 

set protocols ospf traceoptions flag Isa-update 

set protocols ospf traceoptions flag Isa-request 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide. 


To configure global routing tracing operations and tracing operations for OSPF packets: 


1. Configure tracing at the routing options level to collect information about the active routing protocols 
on your routing device. 


[edit] 
user@host# edit routing-options traceoptions 


2. Configure the filename for the global trace file. 


[edit routing-options traceoptions] 
user@host¢# set file routing-log 


3. Configure the filename for the OSPF trace file. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf traceoptions 
user@host¢# set file ospf-log 


4. Configure the maximum number of trace files. 


[edit protocols ospf traceoptions] 
user@host# set file files 5 
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5. Configure the maximum size of each trace file. 


[edit protocols ospf traceoptions] 
user@host# set file size 10k 


6. Configure tracing flags. 


[edit protocols ospf traceoptions] 
user@host# set flag Isa-ack 

user@host# set flag database-description 
user@host# set flag hello 

user@host# set flag Isa-update 
user@host# set flag Isa-request 


7. |If you are done configuring the device, commit the configuration. 


[edit protocols ospf traceoptions] 
user@host# commit 


Results 


Confirm your configuration by entering the show routing-options and the show protocols ospf commands. 
If the output does not display the intended configuration, repeat the instructions in this example to correct 
the configuration. 


user@host# show routing-options 
traceoptions { 
file routing-log; 


user@host# show protocols ospf 
traceoptions { 

file ospf-log size 10k files 5; 

flag Isa-ack; 

flag database-description; 

flag hello; 

flag Isa-update; 

flag Isa-request; 
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To confirm your OSPFv3 configuration, enter the show routing-options and the show protocols ospf3 
commands. 


Tracing SPF Calculations 


CLI Quick Configuration 


To quickly trace SPF calculations, copy the following commands and paste them into the CLI. 


[edit] 
set protocols ospf traceoptions file ospf-log 
set protocols ospf traceoptions flag spf 


Step-by-Step Procedure 
To configure SPF tracing operations for OSPF: 


1. Configure the filename for the OSPF trace file. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf traceoptions 
user@host¢# set file ospf-log 


2. Configure the SPF tracing flag. 


[edit protocols ospf traceoptions] 
user@host# set flag spf 


3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf traceoptions] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 
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user@host# show protocols ospf 
traceoptions { 

file ospf-log ; 

flag spf; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Tracing Link-State Advertisements 


CLI Quick Configuration 


To quickly trace the creation, receipt, and retransmission of all LSAs, copy the following commands and 
paste them into the CLI. 


[edit] 

set protocols ospf traceoptions file ospf-log 
set protocols ospf traceoptions flag Isa-request 
set protocols ospf traceoptions flag Isa-update 
set protocols ospf traceoptions flag Isa-ack 


Step-by-Step Procedure 


To configure link-state advertisement tracing operations for OSPF: 


1. Configure the filename for the OSPF trace file. 


NOTE: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy 
level. 


[edit] 
user@host# edit protocols ospf traceoptions 
user@host¢# set file ospf-log 


2. Configure the link-state advertisement tracing flags. 


[edit protocols ospf traceoptions] 
user@host# set flag Isa-request 
user@host# set flag Isa-update 
user@host# set flag Isa-ack 
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3. If you are done configuring the device, commit the configuration. 


[edit protocols ospf traceoptions] 
user@host# commit 


Results 


Confirm your configuration by entering the show protocols ospf command. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@host# show protocols ospf 
traceoptions { 

file ospf-log; 

flag Isa-request; 

flag Isa-update; 

flag Isa-ack; 


To confirm your OSPFv3 configuration, enter the show protocols ospf3 command. 


Verification 


Confirm that the configuration is working properly. 


Verifying Trace Operations 


Purpose 


Verify that the Trace options field displays the configured trace operations, and verify that the Trace file 
field displays the location on the routing device where the file is saved, the name of the file to receive the 
output of the tracing operation, and the size of the file. 


Action 


From operational mode, enter the show ospf overview extensive command for OSPFv2, and enter the 
show ospf3 overview extensive command for OSPFv3. 
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ignore-Isp-metrics | 654 

import | 655 

inter-area-prefix-export | 657 
inter-area-prefix-import | 658 

interface (Protocols OSPF) | 660 

interface (Protocols OSPF or OSPF3) | 663 
interface-type (Protocols OSPF) | 667 
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Isa-refresh-interval | 678 
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md5 | 680 
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mtu | 686 

neighbor (Protocols OSPF) | 690 
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no-advertise-adjacency-segment (Protocols OSPF) | 693 
no-domain-vpn-tag | 694 
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no-nssa-abr | 698 

no-rfc-1583 | 699 
no-source-packet-routing (Protocols OSPF) | 700 
no-strict-lsa-checking | 701 

node (Protocols OSPF or OSPF3) | 702 
node-link-degradation (Protocols OSPF) | 704 
node-link-protection (Protocols OSPF) | 705 
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node-segment (Protocols OSPF) | 706 
notify-duration | 708 

nssa | 709 

ospf | 710 

ospf3 | 711 

overload (Protocols OSPF) | 712 

passive (Protocols OSPF) | 714 

peer-interface (Protocols OSPF) | 716 
per-prefix-calculation | 717 

poll-interval | 719 

post-convergence-lfa (Protocols OSPF) | 720 
preference (Protocols OSPF) | 721 
prefix-export-limit (Protocols OSPF) | 723 
priority (Protocols OSPF) | 725 

protocols | 727 

realm | 731 

reference-bandwidth (Protocols OSPF) | 732 
remote-backup-calculation(Protocols OSPF) | 734 
retransmit-interval (OSPF) | 735 

rib-group (Protocols OSPF) | 737 
route-type-community | 738 

routing-instances (Multiple Routing Entities) | 739 
secondary (Protocols OSPF) | 741 

sham-link | 742 

sham-link-remote | 744 

shortcuts (Protocols OSPF) | 746 
simple-password | 747 
source-packet-routing-enable (Protocols OSPF) | 748 
source-packet-routing-disable (Protocols OSPF) | 749 
spf-options (Protocols OSPF) | 750 

strict-bfd (Protocols OSPF) | 752 

stub | 753 

stub-network | 754 


summaries | 755 
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te-metric (Protocols OSPF) | 756 

topology (OSPF) | 757 

topology (OSPF Interface) | 759 

traceoptions (Protocols OSPF) | 761 
traffic-engineering (OSPF) | 765 
traffic-engineering (Passive TE Mode) | 768 
transit-delay (OSPF) | 770 

type-7 | 772 

use-post-convergence-lfa (Protocols OSPF) | 774 


virtual-link | 776 
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| admin-group 
Syntax 


admin-group { 
exclude [ group-name ]; 
include-all [ group-name ]; 
include-any [ group-name ]; 
preference [ group-name ]; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options backup-selection destination prefix interface interface 
name], 

[edit logical-systems logical-system-name routing-instances instance-name routing-options backup-selection destination 
prefix interface interface-name], 

[edit routing-instances instance-name routing-options backup-selection destination prefix interface interface-name], 

[edit routing-options backup-selection destination prefix interface interface name] 


Release Information 
Statement introduced in Junos OS Release 14.1. 


Description 


Define the administrative groups criteria for the selection of the backup path. 


NOTE: Configure group names of admin-group under the [edit protocols mpls] hierarchy level. 


Options 
exclude [ group-name ]— Specify the administrative groups to be excluded. The backup path is not selected 


as the loop-free alternate (LFA) or backup next hop if any of the links in the path have any one of the 
listed administrative groups. 


group-name— Name of one or more admin-group defined under the [edit protocols mpls] hierarchy 
level. 


include-all [ group-name ]— Require each link in the backup path to have all the listed administrative groups 
in order to accept the path. 


group-name— Name of one or more admin-group defined under the [edit protocols mpls] hierarchy 
level. 
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include-any [ group-name ]— Require each link in the backup path to have at least one of the listed 
administrative groups in order to select the path. 


group-name— Name of one or more admin-group defined under the [edit protocols mpls] hierarchy 
level. 


preference [ group-name ]— Define an ordered set of administrative groups that specifies the preference 
of the backup path. The leftmost element in the set is given the highest preference. 


group-name— Name of one or more admin-group defined under the [edit protocols mpls] hierarchy 
level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding Backup Selection Policy for IS-IS Protocol 
Configuring Backup Selection Policy for IS-IS Protocol 
Understanding Backup Selection Policy for OSPF Protocol | 442 
backup-selection (Protocols ISIS) 


destination 





interface 
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| allow-route-leaking 


Syntax 


allow-route-leaking; 


Hierarchy Level 


[edit logical-systems name protocols ospf overload], 

[edit logical-systems name routing-instances name protocols ospf overload], 
[edit protocols ospf overload], 

[edit routing-instances name protocols ospf overload], 

[edit protocols ospf3 overload] 


Release Information 
Statement introduced in Junos OS Release 18.2 for MX Series Routers. 


Description 
Allow routes to be leaked when OSPF overload is configured and advertise the external prefixes with 
maximum cost. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Overload Function | 222 
stub-network | 754 


intra-area-prefix | 670 





as-external | 613 
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| area 


Syntax 


area area-id { 
interface interface-name { 
no-eligible-remote-backup; 
passive; 
topology (ipv4-multicast | name) { 
disable; 


} 
virtual-link neighbor-id router-id transit-area area-id { 
topology (ipv4-multicast | name) { 
disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Support for the no-eligible-remote-backup statement introduced in Junos OS Release 15.1. 


Description 
Specify the area identifier for this routing device to use when participating in OSPF routing. All routing 
devices in an area must use the same area identifier to establish adjacencies. 
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Specify multiple area statements to configure the routing device as an area border router. An area border 
router does not automatically summarize routes between areas. Use the area-range statement to configure 
route summarization. By definition, an area border router must be connected to the backbone area either 
through a physical link or through a virtual link. To create a virtual link, include the virtual-link statement. 


To specify that the routing device is directly connected to the OSPF backbone, include the area 0.0.0.0 
statement. 


All routing devices on the backbone must be contiguous. If they are not, use the virtual-link statement to 
create the appearance of connectivity to the backbone. 


You can also configure any interface that belongs to one or more topologies to advertise the direct interface 
addresses without actually running OSPF on that interface. By default, OSPF must be configured on an 
interface in order for direct interface addresses to be advertised as interior routes. 


NOTE: If you configure an interface with the passive statement, it applies to all the topologies 
to which the interface belongs. You cannot configure an interface as passive for only one specific 
topology and have it remain active for any other topologies to which it belongs. 


Options 
area-id—Area identifier. The identifier can be up to 32 bits. It is common to specify the area number as a 
simple integer or an IP address. Area number 0.0.0.0 is reserved for the OSPF backbone area. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
Understanding Multiple Address Families for OSPFv3 | 57 
virtual-link | 776 
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| area-range 
Syntax 


area-range network/mask-length <exact> <override-metric metric> <restrict>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssal, 

[edit logical-systems logical-system-name realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssal], 

[edit logical-systems logical-system-name routing-instances routing-instance-name realm (ipv4-unicast | ipv4-multicast 
| ipv6-multicast) area area-id], 

[edit protocols (ospf | ospf3) area area-id], 

[edit protocols (ospf | ospf3) area area-id nssal, 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa], 

[edit routing-instances routing-instance-name realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
(Area border routers only) For an area, summarize a range of IP addresses when sending summary link 
advertisements (within an area). To summarize multiple ranges, include multiple area-range statements. 


For a not-so-stubby area (NSSA), summarize a range of IP addresses when sending NSSA link-state 
advertisements. The specified prefixes are used to aggregate external routes learned within the area when 
the routes are advertised to other areas. To specify multiple prefixes, include multiple area-range statements. 
All external routes learned within the area that do not fall into one of the prefixes are advertised individually 
to other areas. 


Default 
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By default, area border routing devices do not summarize routes being sent from one area to other areas, 
but rather send all routes explicitly. 


Options 
exact—(Optional) Summarization of a route is advertised only when an exact match is made with the 
configured summary range. 


mask-length—Number of significant bits in the network mask. 
network—IP address. You can specify one or more IP addresses. 


override-metric metric—(Optional) Override the metric for the IP address range and configure a specific 
metric value. 


restrict—(Optional) Do not advertise the configured summary. This hides all routes that are contained 
within the summary, effectively creating a route filter. 
Range: 1 through 16,777,215 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Summarizing Ranges of Routes in OSPF Link-State Advertisements 
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| as-external 


Syntax 


as-external; 


Hierarchy Level 


[edit logical-systems name protocols ospf overload], 

[edit logical-systems name routing-instances name protocols ospf overload], 
[edit protocols ospf overload], 

[edit routing-instances name protocols ospf overload], 

[edit protocols ospf3 overload] 


Release Information 
Statement introduced in Junos OS Release 18.2 for MX Series Routers. 


Description 


Advertise OSPF AS external prefixes with maximum usable metric. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Overload Function | 222 
allow-route-leaking | 608 


stub-network | 754 





intra-area-prefix | 670 
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| authentication 


Syntax 


authentication { 
md5 key-identifier { 
key key-value; 
start-time YYYY-MM-DD.hh:mm; 
} 


simple-password key; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols ospf area area-id virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
virtual-link], 

[edit protocols ospf area area-id interface interface-namel], 

[edit protocols ospf area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id virtual-link] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Configure an authentication key (password). Neighboring routers use the password to verify the authenticity 
of packets sent from this interface. 


All routers that are connected to the same IP subnet must use the same authentication scheme and 
password. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Understanding OSPFv2 Authentication | 246 

Example: Configuring MD5 Authentication for OSPFv2 Exchanges | 252 
Example: Configuring a Transition of MD5 Keys on an OSPF v2 Interface | 255 
Example: Configuring Simple Authentication for OSPFv2 Exchanges | 249 


| backup-selection (Protocols OSPF or OSPF3) 


Syntax 


backup-selection { 
destination prefix { 
interface (interface-name| all){ 

admin-group { 
exclude [ group-name ]; 
include-all [ group-name ]; 
include-any [ group-name ]; 
preference [ group-name ]; 

} 

bandwidth-greater-equal-primary; 

dest-metric (highest | lowest); 

downstream-paths-only; 

metric-order [ root dest ]; 

node { 
exclude [ node-address ]; 
preference [ node-address ]; 

} 

protection-type (link | node | node-link); 

root-metric (highest | lowest); 

srlg (loose | strict); 

evaluation-order [ admin-group srlg bandwidth protection-type node metric ] ; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 

[edit logical-systems logical-system-name routing-instances instance-name routing-options], 
[edit routing-instances instance-name routing-options], 

[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 
Define backup selection policies, per prefix per primary next-hop interface, to enforce loop-free alternate 


(LFA) selection based on admin-group, srlg, bandwidth, protection-type, node, and metric attributes of the 
backup path. 
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The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 453 
Configuring Backup Selection Policy for the OSPF Protocol | 444 
Understanding Backup Selection Policy for OSPF Protocol | 442 
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| backup-spf-options (Protocols OSPF) 


Syntax 


backup-spf-options { 

disable; 
downstream-paths-only; 
no-install; 
node-link-degradation; 
per-prefix-calculation { 

all; 

externals; 

stubs; 

summary; 
} 


remote-backup-calculation; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf topology (default | name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| name)]; 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf topology (default | name)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf topology (default | name)] 


Release Information 

Statement introduced in Junos OS Release 10.0. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 

node-link-degradation, per-prefix-calculation, and remote-backup-calculation options introduced in Junos 
OS Release 15.1. 

Support for remote-backup-calculation option introduced in Junos OS Release 18.2R1 for QFX5100, 
QFX5110, and QFX5200 switches. 


Description 

Configure options for running the shortest-path-first (SPF) algorithm for backup next hops for protected 
interfaces. Use these options to override the default behavior of having Junos OS calculate backup paths 
for all the topologies in an instance when at least one interface is configured with link protection or 
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node-link protection. These options also enable you to change the default behavior for a specific topology 
in an OSPF instance. 


Options 


disable—Do not calculate backup next hops for the specified instance or topology. 


downstream-paths-only—Calculate and install only downstream paths as defined in RFC 5286, Basic 
Specification for IP Fast Reroute: Loop-Free Alternates for the specified instance or topology. 


no-install—Do not install the backup next hops for the specified instance or topology. 


node-link-degradation—Degrade to link protection when node-link protection is not available. A link 
protecting loop-free alternate (LFA) is used when node-link protecting LFA is not available in the topology 
for any of the protected links. 


per-prefix-calculation—Calculate backup next hops for non-best prefix originators. 


remote-backup-calculation— Determine the remote LFA backup paths from the point of local repair (PLR) 
in an OSPF network. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control-level—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Backup SPF Options for Protected OSPF Interfaces | 338 
link-protection | 676 


node-link-protection | 705 





remote-backup-calculation | 734 


| bandwidth-based-metrics 


Syntax 


bandwidth-based-metrics { 
bandwidth value; 
metric number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology topology-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology topology-name], 

[edit logical-systems logical-system-name routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | 
ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf area area-id interface interface-name topology topology-name], 

[edit protocols ospf3 realm (ivp4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology 
topology-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 9.5. 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 

Specify a set of bandwidth threshold values and associated metric values for an OSPF interface or for a 
topology on an OSPF interface. When the bandwidth of an interface changes, Junos OS automatically sets 
the interface metric to the value associated with the appropriate bandwidth threshold value. 


Options 
bandwidth value—Specify the bandwidth threshold in bits per second. 
Range: 9600 through 1,000,000,000,000,000 


metric number—Specify a metric value to associate with a specific bandwidth value. 
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Range: 1 through 65,535 


NOTE: You must also configure a static metric value for the OSPF interface or topology with 
the metric statement. Junos OS uses this value to calculate the cost of a route from the OSPF 


interface or topology if the bandwidth for the interface is higher than of any bandwidth threshold 
values configured for bandwidth-based metrics. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217 
metric | 682 


Example: Dynamically Adjusting OSPF Interface Metrics Based on Bandwidth | 217 


| bfd-liveness-detection (Protocols OSPF) 


Syntax 


bfd-liveness-detection { 
authentication { 
algorithm algorithm-name; 
key-chain key-chain-name; 
loose-check; 
} 
detection-time { 
threshold milliseconds; 
} 
full-neighbors-only 
holddown-interval holddown-interval; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
multiplier number; 
no-adaptation; 
transmit-interval { 
minimum-interval milliseconds; 
threshold milliseconds; 
} 


version (1 | automatic); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 
[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 


area-id interface interface-name], 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 


interface interface-namel, 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Statement introduced in Junos OS Release 9.0 for EX Series switches. 
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detection-time threshold and transmit-interval threshold options added in Junos OS Release 8.2. 
Support for logical systems introduced in Junos OS Release 8.3. 

no-adaptation option introduced in Junos OS Release 9.0. 

no-adaptation option introduced in Junos OS Release 9.0 for EX Series switches. 

Support for OSPFv3 introduced in Junos OS Release 9.3. 

Support for OSPFv3 introduced in Junos OS Release 9.3 for EX Series switches. 
full-neighbors-only option introduced in Junos OS Release 9.5. 

full-neighbors-only option introduced in Junos OS Release 9.5 for EX Series switches. 
holddown-interval option introduced in Junos OS Release 19.4 for MX Series routers. 
authentication algorithm, authentication key-chain, and authentication loose-check options introduced 
in Junos OS Release 9.6. 

Statement introduced in Junos OS Release 12.1 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure bidirectional failure detection timers and authentication for OSPF. 


The remaining statements are explained separately. See CLI Explorer. 


Options 

authentication algorithm algorithm-name —Configure the algorithm used to authenticate the specified 
BFD session: simple-password, keyed-md5, keyed-sha-1, meticulous-keyed-md5, or 
meticulous-keyed-sha-1. 


authentication key-chain key-chain-name—Associate a security key with the specified BFD session using 
the name of the security keychain. The name you specify must match one of the keychains configured in 
the authentication-key-chains key-chain statement at the [edit security] hierarchy level. 


authentication loose-check—(Optional) Configure loose authentication checking on the BFD session. Use 
only for transitional periods when authentication may not be configured at both ends of the BFD session. 


detection-time threshold milliseconds—Configure a threshold for the adaptation of the BFD session 
detection time. When the detection time adapts to a value equal to or greater than the threshold, a single 
trap and a single system log message are sent. 


full-neighbors-only—Establish BFD sessions only for OSPF neighbors in the full state. The default behavior 
is to establish BFD sessions for all OSPF neighbors. 


holddown-interval holddown-interval—Time to hold the session-UP notification to the client. 
Range: O through 255000 milliseconds 


minimum-interval milliseconds—Configure the minimum interval after which the local routing device 
transmits a hello packet and then expects to receive a reply from the neighbor with which it has established 
a BFD session. Optionally, instead of using this statement, you can configure the minimum transmit and 
receive intervals separately using the transmit-interval minimum-interval and minimum-receive-interval 
statements. 


Range: 1 through 255,000 milliseconds 


minimum-receive-interval milliseconds—Configure the minimum interval after which the routing device 
expects to receive a reply from a neighbor with which it has established a BFD session. Optionally, instead 
of using this statement, you can configure the minimum receive interval using the minimum-interval 
statement. 


Range: 1 through 255,000 milliseconds 


multiplier number—Configure the number of hello packets not received by a neighbor that causes the 
originating interface to be declared down. 

Range: 1 through 255 

Default: 3 


no-adaptation—Specify that BFD sessions should not adapt to changing network conditions. We recommend 
that you not disable BFD adaptation unless it is preferable not to have BFD adaptation enabled in your 
network. 


transmit-interval threshold milliseconds—Configure the threshold for the adaptation of the BFD session 
transmit interval. When the transmit interval adapts to a value greater than the threshold, a single trap 
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and a single system message are sent. The interval threshold must be greater than the minimum transmit 
interval. 


Range: 0 through 4,294,967,295 (2°* - 1) 


transmit-interval minimum-interval milliseconds—Configure the minimum interval at which the routing 
device transmits hello packets to a neighbor with which it has established a BFD session. Optionally, instead 
of using this statement, you can configure the minimum transmit interval using the minimum-interval 
statement. 


Range: 1 through 255,000 


version—Configure the BFD version to detect: 1 (BFD version 1) or automatic (autodetect the BFD version). 


Default: automatic 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring BFD for OSPF | 294 
Example: Configuring BFD Authentication for OSPF 
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| context-identifier (Protocols OSPF) 


Syntax 


context-identifer identifier 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf |ospf3) area area-id], 
[edit protocols (ospf | ospf3) area area-id | 


Release Information 

Statement introduced in Junos OS Release 10.4. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure OSPF context-identifier information. 


Options 
identifer—|Pv4 address that defines a protection pair. The context identifier is manually configured on 
both the primary and protector provider edge (PE) devices. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


show ospf context-identifier | 816 


| database-protection 


Syntax 


database-protection { 
ignore-count number; 
ignore-time seconds; 
maximum-lsa number; 
reset-time seconds; 
warning-only; 
warning-threshold percent; 


Hierarchy Level 


[edit protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-unicast | 
ipv6-multicast)] 


Release Information 

Statement introduced in Junos OS Release 10.2. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Configure the maximum number of link-state advertisements (LSAs) that are not generated by the router 
or switch in a given OSPF instance. 


Default 
By default, OSPF database protection is not enabled. 


Options 
ignore-count number—Configure the number of times the database can enter the ignore state. When the 
ignore count is exceeded, the database enters the isolate state. 

Range: 1 through 32 

Default: 5 


ignore-time seconds—Configure the time the database must remain in the ignore state before it resumes 
regular operations (enters retry state). 


Range: 30 through 3,600 seconds 
Default: 300 seconds 
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maximum-lsa number—Configure the maximum number of LSAs whose advertising router ID is different 
from the local router ID in a given OSPF instance. This includes external LSAs as well as LSAs with any 
scope, such as the link, area, and autonomous system (AS). This value is mandatory. 


Range: 1 through 1,000,000 
Default: None 


reset-time seconds—Configure the time period during which the database must operate without being in 
the ignore or isolate state before it is reset to a normal operating state. 


Range: 60 through 86,400 seconds 
Default: 600 seconds 


warning-only—Specify that only a warning should be issued when the maximum LSA number is exceeded. 


If configured, no other action is taken against the database. 


warning-threshold percent—Configure the percentage of the maximum number of LSAs to be exceeded 
before a warning message is logged. 

Range: 30 through 100 percent 

Default: 75 percent 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Database Protection Overview | 432 
Configuring OSPF Database Protection | 433 
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| dead-interval 


Syntax 


dead-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how long OSPF waits before declaring that a neighboring routing device is unavailable. This is an 
interval during which the routing device receives no hello packets from the neighbor. 


Options 
seconds—Interval to wait. 
Range: 1 through 65,535 seconds 


Default: Four times the hello interval—40 seconds (broadcast and point-to-point networks); 120 seconds 
(nonbroadcast multiple access (NBMA) networks) 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers | 283 
Configuring RSVP and OSPF for LMP Peer Interfaces 
hello-interval | 650 
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| default-lsa 


Syntax 


default-lsa { 
default-metric metric; 
metric-type type; 
type-7; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssal, 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id nssal], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssal], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id nssal, 

[edit protocols (ospf | ospf3) area area-id nssal, 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssal, 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id nssa] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 

On area border routers only, for a not-so-stubby area (NSSA), inject a default link-state advertisement 
(LSA) with a specified metric value into the area. The default route matches any destination that is not 
explicitly reachable from within the area. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 

Example: Configuring OSPF Not-So-Stubby Areas | 107 
nssa | 709 

stub | 753 
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| default-metric 


Syntax 


default-metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id stub], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id nssa default-lsa], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id stub], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssa default-Isa], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
stub], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id nssa default-Isa], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id stub], 

[edit protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit protocols (ospf | ospf3) area area-id stub], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id nssa default-lsa], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id stub], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id stub], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id nssa default-lsal, 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id stub] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 

On area border routing devices only, for a stub area, inject a default route with a specified metric value 
into the area. The default route matches any destination that is not explicitly reachable from within the 
area. 


Options 
metric—Metric value. 
Range: 1 through 16,777,215 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
nssa | 709 
stub | 753 
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| demand-circuit 


Syntax 


demand-circuit; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
sham-link-remote], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Support for the realm statement introduced in Junos OS Release 9.2. 


Description 


Configure an interface as a demand circuit. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Demand Circuits | 43 
Example: Configuring OSPFv2 Sham Links | 542 
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| destination (Protocols OSPF or OSPF3) 


Syntax 


destination prefix { 
interface (interface-name |all) { 
admin-group { 
exclude [ group-name ]; 
include-all [ group-name ]; 
include-any [ group-name ]; 
preference [ group-name ]; 
} 
bandwidth-greater-equal-primary; 
dest-metric (highest | lowest); 
downstream-paths-only ; 
evaluation-order [ admin-group srlg bandwidth protection-type neighbor neighbor-tag metric ]; 
metric-order [ root dest ]; 
node { 
exclude [ node-address ]; 
preference [ node-address ]; 
} 
protection-type (link |node | node-link); 
root-metric (highest | lowest) ; 
srlg (loose |strict); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options backup-selection], 
[edit logical-systems logical-system-name routing-instances instance-name routing-options backup-selection], 
[edit routing-instances instance-name routing-options backup-selection], 


[edit routing-options backup-selection] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Define the backup selection policy for a particular destination prefix or for all the prefixes. 


Options 
prefix— Destination prefix name and prefix length. You can specify O/O for the IPv4 least-specific prefix 
or 0::0/0 for the IPvé6 least-specific prefix. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


disable (Protocols OSPF) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 7.5. 


Description 
Disable LDP synchronization for OSPF. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Synchronization Between LDP and OSPF | 234 
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| disable (OSPF) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf area area-id peer-interfaceinterface-namel], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | 
ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3)], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) virtual-link], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 
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Description 
Disable OSPF, an OSPF interface, or an OSPF virtual link. 


By default, control packets sent to the remote end of a virtual link must be forwarded using the default 
topology. In addition, the transit area path consists only of links that are in the default topology. You can 
disable a virtual link for a configured topology, but not for a default topology. Include the disable statement 
at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id topology 
name] hierarchy level. 


NOTE: If you disable the virtual link by including the disable statement at the [edit protocols 
ospf area area-id virtual-link neighbor-id router-id transit-area area-id] hierarchy level, you disable 
the virtual link for all topologies, including the default topology. You cannot disable the virtual 
link only in the default topology. 


Default 


The configured object is enabled (operational) unless explicitly disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Configurations | 35 
Configuring RSVP and OSPF for LMP Peer Interfaces 


640 


| domain-id 
Syntax 


domain-id domain-id; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 
[edit routing-instances routing-instance-name protocols (ospf | ospf3)] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.0 for EX Series switches. 


Description 


Specify a domain ID for a route. The domain ID identifies the OSPF domain from which the route originated. 


Options 

domain-id—You can specify either an IP address or an IP address and a local identifier using the following 
format: ip-address:local-identifier. lf you do not specify a local identifier with the IP address, the identifier 
is assumed to have a value of O. 


Default: If the router ID is not configured in the routing instance, the router ID is derived from an interface 
address belonging to the routing instance. The default OSPF domain ID is the null value 0.0.0.0. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routing Between PE and CE Routers in Layer 3 VPNs 
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| domain-vpn-tag 
Syntax 


domain-vpn-tag number; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 
[edit routing-instances routing-instance-name protocols (ospf | ospf3)] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.0 for EX Series switches. 


Description 
Set a virtual private network (VPN) tag for OSPFv2 external routes generated by the provider edge (PE) 
routing device. 


Options 
number—VPN tag. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routing Between PE and CE Routers in Layer 3 VPNs 
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| export 
Syntax 


export [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Apply one or more policies to routes being exported from the routing table into OSPF. 


Options 
policy-names—Name of one or more policies. 
Required Privilege Level 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Routing Policy | 440 
Import and Export Policies for Network Summaries Overview | 505 


import | 655 
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import | 655 
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| external-preference (Protocols OSPF) 


Syntax 


external-preference preference; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast } ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Set the route preference for OSPF external routes. 


Options 

preference—Preference value. 
Range: 0 through 4,294,967,295 (2°* - 1) 
Default: 150 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Controlling OSPF Route Preferences | 220 
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preference | 721 
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flood-reduction 


Syntax 


flood-reduction; 


Hierarchy Level 


[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interfaces interface-name], 

[edit protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area 
area-id interfaces interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) 
area area-id interfaces interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast 
| ipv4-unicast | ipv6-multicast) area area-id interfaces interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit-area area-id], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id 
transit-area transit-area area-id], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id 
transit-area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link neighbor-id router-id transit-area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address ], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
sham-link-remote address], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 9.6. 
Statement introduced in Junos OS Release 10.4 for EX Series switches. 


Description 

Specify to send self-generated link-state advertisements (LSAs) with the DoNotAge bit set. As a result, 
self-originated LSAs are not reflooded every 30 minutes, as required by OSPF by default. An LSA is refreshed 
only when the content of the LSA changes, which reduces OSPF traffic overhead in stable topologies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring OSPF Refresh and Flooding Reduction in Stable Topologies | 232 
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| graceful-restart (Protocols OSPF) 


Syntax 


graceful-restart { 
disable; 
helper-disable (standard | restart-signaling | both); 
no-strict-lsa-checking; 
notify-duration seconds; 
restart-duration seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 
[edit protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for the no-strict-lsa-checking statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the helper mode standard, restart-signaling, and both options introduced in Junos OS 
Release 11.4. 

Statement introduced in Junos OS Release 12.1 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure graceful restart for OSPF. 


Graceful restart allows a routing device to restart with minimal effects to the network, and is enabled for 
all routing protocols at the [edit routing-options] hierarchy level. 


Options 
disable—Disable graceful restart for OSPF. 


helper-disable (standard | restart-signaling| both)—Disable helper mode for graceful restart. When helper 
mode is disabled, a device cannot help a neighboring device that is attempting to restart. Beginning with 
Junos OS Release 11.4, you can configure restart signaling-based helper mode for OSPF v2 graceful restart 
configurations. The standard, restart-signaling, and both options are only supported for OSPFv2. Specify 
standard to disable helper mode for standard graceful restart (based on RFC 3623). Specify restart-signaling 
to disable helper mode for restart signaling-based graceful restart (based on RFC 4811, RFC 4812, and 
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RFC 4813). Specify both to disable helper mode for both standard and restart signaling-based graceful 
restart. The last committed statement takes precedence over the previously configured statement. 


Default: Helper mode is enabled by default. For OSPFv2, both standard and restart-signaling based helper 
modes are enabled by default. 


no-strict-Ilsa-checking—Disable strict OSPF link-state advertisement (LSA) checking to prevent the 
termination of graceful restart by a helping router. LSA checking is enabled by default. 


NOTE: The helper-disable statement and the no-strict-Ilsa-checking statement cannot be 
configured at the same time. If you attempt to configure both statements at the same time, the 
routing device displays a warning message when you enter the show protocols (ospf | ospf3) 
command. 


notify-duration seconds—Estimated time needed to send out purged grace LSAs over all the interfaces. 
Range: 1 through 3600 seconds 
Default: 30 seconds 


restart-duration seconds—Estimated time needed to reacquire a full OSPF neighbor from each area. 
Range: 1 through 3600 seconds 
Default: 180 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Graceful Restart for OSPF | 309 

Example: Configuring the Helper Capability Mode for OSPFv2 Graceful Restart | 315 
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart | 320 
Example: Disabling Strict LSA Checking for OSPF Graceful Restart | 324 
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| hello-interval (Protocols OSPF) 


Syntax 


hello-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how often the routing device sends hello packets out the interface. The hello interval must be the 
same for all routing devices on a shared logical IP network. 


Options 
seconds—Time between hello packets, in seconds. 
Range: 1 through 255 seconds 


Default: 10 seconds (broadcast and point-to-point networks); 30 seconds (nonbroadcast multiple access 
[NBMA] networks) 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers | 283 
Configuring RSVP and OSPF for LMP Peer Interfaces 
dead-interval | 629 
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| helper-disable (OSPF) 


Syntax 


helper-disable < both | restart-signaling | standard >; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf graceful-restart], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf graceful-restart], 
[edit protocols ospf graceful-restart], 

[edit routing-instances routing-instance-name protocols ospf graceful-restart] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Options both, restart-signaling, and standard introduced in Junos OS Release 11.4. 
Statement introduced in Junos OS Release 12.1 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 

Disable helper mode for graceful restart. When helper mode is disabled, a router cannot help a neighboring 
router that is attempting to restart. The last committed statement takes precedence over the previously 
configured statement. 


Default 
Helper mode is enabled by default for OSPF. 


Options 


both—(Optional) Disable helper mode for both standard and restart signaling-based graceful restart. 


restart-signaling—(Optional) Disable helper mode for restart signaling-based graceful restart (based on 
RFC 4811, RFC 4812, and RFC 4813). 


NOTE: Restart signaling-based helper mode is not supported for OSPFv3 configurations. 


standard—(Optional) Disable helper mode for standard graceful restart (based on RFC 3623). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring Routing Protocols Graceful Restart 
Configuring Graceful Restart for MPLS-Related Protocols 


| hold-time (Protocols OSPF) 


Syntax 


hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit protocols ospf area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 7.5. 


Description 


Configure the time period to advertise the maximum cost metric for a link that is not fully operational. 


Options 

seconds—Hold-time value. 
Range: 1 through 65,535 seconds 
Default: Infinity 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Synchronization Between LDP and OSPF | 234 
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| ignore-Ilsp-metrics 
Syntax 


ignore-Isp-metrics; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf traffic-engineering 
shortcuts], 

[edit protocols ospf traffic-engineering ], 

[edit routing-instances routing-instance-name protocols ospf traffic-engineering shortcuts] 


Release Information 

Statement introduced in Junos OS Release 7.5. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for (OSPFv3) introduced in Junos OS Release 9.4. 

Support for (OSPFv3) introduced in Junos OS Release 9.4 for EX Series switches. 


Description 


Ignore RSVP LSP metrics in OSPF traffic engineering shortcut calculations. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Enabling OSPF Traffic Engineering Support | 394 
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| import 
Syntax 


import [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Filter OSPF routes from being added to the routing table. 


Options 
policy-names—Name of one or more policies. 
Required Privilege Level 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Routing Policy | 440 
Import and Export Policies for Network Summaries Overview | 505 


export | 642 
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| export | 642 
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| inter-area-prefix-export 
Syntax 


inter-area-prefix-export [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf3 area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ip4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id], 

[edit protocols ospf3 area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-muticast | ipv6-multicast) 
area area-id] 


Release Information 

Statement introduced in Junos OS Release 9.1. 

Statement introduced in Junos OS Release 9.1 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Apply an export policy for OSPFv3 to specify which interarea prefix link-state advertisements (LSAs) are 
flooded into an area. 


Options 
policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term 
term-name] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Import and Export Policies for Network Summaries Overview | 505 
inter-area-prefix-import | 658 


Routing Policies, Firewall Filters, and Traffic Policers User Guide 
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| inter-area-prefix-import 
Syntax 


inter-area-prefix-import [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf3 area area-id], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id], 

[edit protocols ospf3 area area-id], 

[edit protocols ospf3 realm (ip4-unicast | ipv4-multicast | ipv6-multicast)], area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id] 


Release Information 

Statement introduced in Junos OS Release 9.1. 

Statement introduced in Junos OS Release 9.1 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Apply an import policy for OSPFv3 to specify which routes learned from an area are used to generate 
interarea prefixes into other areas. 


Options 
policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term 
term-name] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Import and Export Policies for Network Summaries Overview | 505 


inter-area-prefix-export | 657 
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Routing Policies, Firewall Filters, and Traffic Policers User Guide 
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| interface (Protocols OSPF) 


Syntax 


interface interface-name { 
disable; 
authentication key <key-id identifier>; 
bfd-liveness-detection { 
authentication { 
algorithm algorithm-name; 
key-chain key-chain-name; 
loose-check; 
} 
detection-time { 
threshold milliseconds; 
} 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
transmit-interval { 
threshold milliseconds; 
minimum-interval milliseconds; 
} 
multiplier number; 
} 
dead-interval seconds; 
demand-circuit; 
hello-interval seconds; 
ipsec-sa name; 
interface-type type; 
Idp-synchronization { 
disable; 
hold-time seconds; 
} 
metric metric; 
neighbor address <eligible>; 
no-interface-state-traps; 
passive; 
poll-interval seconds; 
priority number; 
retransmit-interval seconds; 
te-metric metric; 
topology (ipv4-multicast | name) { 
metric metric; 
} 


transit-delay seconds; 
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Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id], 

[edit protocols (ospf | ospf3) area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the topology statement introduced in Junos OS Release 9.0. 

Support for the topology statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 

Support for the no-interface-state-traps statement introduced in Junos OS Release 10.3. This statement 
is supported only for OSPFv2. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 


Description 


Enable OSPF routing on a routing device interface. 


You must include at least one interface statement in the configuration to enable OSPF on the routing 
device. 
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Options 

interface-name—Name of the interface. Specify the interface by IP address or interface name for OSPFv2, 
or only the interface name for OSPFv3. Using both the interface name and IP address of the same interface 
produces an invalid configuration. To configure all interfaces, you can specify all. Specifying a particular 
interface and all produces an invalid configuration. 


NOTE: For nonbroadcast interfaces, specify the IP address of the nonbroadcast interface as 
interface-name. 


The remaining statements are explained separately. See CLI Explorer. 


NOTE: You cannot run both OSPF and ethernet-tcc encapsulation between two Juniper Networks 
routing devices. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Configurations | 35 
Example: Configuring Multiple Address Families for OSPFv3 | 58 
neighbor | 690 


| interface (Protocols OSPF or OSPF3) 


Syntax 


interface (interface-name | all) { 
admin-group { 
exclude [ group-name ]; 
include-all [ group-name ]; 
include-any [ group-name ]; 
preference [ group-name ]; 
} 
bandwidth-greater-equal-primary; 
dest-metric (highest | lowest); 
downstream-paths-only ; 
evaluation-order [ admin-group srlg bandwidth protection-type node metric ]; 
metric-order [ root dest ]; 
node { 
exclude [ node-address ]; 
preference [ node-address ]; 
} 
protection-type (link | node] node-link); 
root-metric (highest | lowest); 
srlg (loose |strict); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options backup-selection destination prefix], 
[edit logical-systems logical-system-name routing-instances instance-name routing-options backup-selection destination 


prefix], 
[edit routing-instances instance-name routing-options backup-selection prefix], 
[edit routing-options backup-selection destination prefix] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Define the backup selection policy for a specific primary next hop. 


Options 


interface-name— Name of the primary next-hop interface. 


all— All the interfaces. 
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bandwidth-greater-equal-primary— Allow the selection of the backup next hop only if the bandwidth is 
greater than or equal to the bandwidth of the primary next hop. 


dest-metric (highest lowest)—Specifiy the metric from the one-hop neighbor or from the remote router 
such as an RSVP backup label-switched-path (LSP) tail-end router to the final destination. 


highest— Select the backup path that has the highest destination metric. 
lowest— Select the backup path that has the lowest destination metric. 
downstream-paths-only— Select the backup path that is a downstream path to the destination. 


evaluation-order [ admin-group srlg bandwidth protection-type node metric ]—Control the order and the 
criteria of evaluating the backup path. The default order of evaluation is admin-group, srlg, bandwidth, 
protection-type, node and metric. 


NOTE: For the explicitly configured evaluation order, only the listed attributes influence the 
selection of the backup path. 
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metric-order [ root dest ]— Specify the order of preference of the root and the destination metric during 
the backup path selection. The preference order can be: 


e [root dest] — Backup path selection or preference is first based on the root-metric criteria. If the 
criteria of all the root-metric is the same, then the selection or preference is based on the dest-metric. 


e [dest root] — Backup path selection or preference is first based on the dest-metric criteria. If the 
criteria of all the dest-metric is the same, then the selection is based on the root-metric. 


NOTE: Backup path selection or preference is first based on the dest-metric criteria. If the 
criteria of all the dest-metric is the same, then the selection is based on the root-metric. By 
default, backup paths with lower destination metric criteria are selected or preferred. If the 
criteria is the same, then the lowest root metric criteria is preferred or selected. 


root— The metric to a one-hop neighbor or a remote router. 
dest— The metric from a one-hop neighbor or remote router to the final destination. 


protection-type (link | node | node-link)—Specify the required protection type of the backup path. 


NOTE: If no protection-type is configured, then by default the first best path that matches all 
the other criteria is executed. 


link— Select the backup path that provides link protection. 
node— Select the backup path that provides node protection. 


node-link— Allow either node or link protection LFA where node-protection LFA is preferred over 


link-protection LFA. 


root-metric (highest lowest)—Specify the metric to the one-hop neighbor or to the remote router such as 
an RSVP backup label-switched-path (LSP) tail-end router. 


highest— Select the highest root metric. 


lowest— Select the lowest root metric. 
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srlg (loose | strict)— Define the backup selection to either allow or reject the common shared risk link groups 
(SRLGs) between the primary link and any link in the backup path. 


loose— Allow the backup path that has common srlgs between the primary link and any link in the 
backup path. A backup path with a fewer number of srlg collisions is preferred. 


strict— Reject the backup path that has common srlgs between the primary next-hop link and each 
link in the backup path. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 453 
Configuring Backup Selection Policy for the OSPF Protocol | 444 

Understanding Backup Selection Policy for OSPF Protocol | 442 

backup-selection (Protocols ISIS) 
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| interface-type (Protocols OSPF) 


Syntax 


interface-type (nbma | p2mp | p2mp-over-lan | p2p) { 

ipsec-sa; 
Idp-synchronization { 

(disable | enable); 

hold-time; 
} 
metric; 
mtu; 
neighbor address { 

eligible; 
} 
no-advertise-adjacency-segment; 
no-eligible-backup; 
no-eligible-remote-backup; 
no-interface-state-traps; 
no-neighbor-down-notification; 
node-link-protection; 
passive { 

traffic-engineering { 

remote-node-id; 
remote-node-router-id; 


} 

poll-interval; 

priority; 
retransmit-interval; 
secondary; 

te-metric; 

topology (default | ipv4-multicast | name); 
transit-delay; 
bandwidth-based-metrics; 
bfd-liveness-detection; 
dead-interval; 
demand-circuit; 

disable; 
dynamic-neighbors; 
flood-reduction; 
hello-interval:; 
link-protection; 
own-router-|sa; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast 
| ipv4-unicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-multicast | ipv4-unicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for OSPF v3 for interface type p2p only introduced in Junos OS Release 9.4. You cannot configure 
other interface types for OSPFv3. 

Support for OSPF v3 for interface type p2mp is introduced in Junos OS Release 18.1R1. 

Support for OSPFv3 for interface type p2p only introduced in Junos OS Release 9.4 for EX Series switches. 


Description 


Specify the type of interface. 


By default, the software chooses the correct interface type based on the type of physical interface. 
Therefore, you should never have to set the interface type. The exception to this is for NBMA interfaces, 
which default to an interface type of point-to-multipoint. To have these interfaces explicitly run in 
Nonbroadcast multiaccess (NBMA) mode, configure the nbma interface type, using the IP address of the 
local ATM interface. 


In Junos OS Release 9.3 and later, a point-to-point interface can be an Ethernet interface without a subnet. 


Default 


The software chooses the correct interface type based on the type of physical interface. 
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Options 
nbma (OSPF v2 only)—Nonbroadcast multiaccess (NBMA) interface 


p2mp—Point-to-multipoint interface 
p2mp-over-lan—Point-to-multipoint over LAN mode 
p2p—Point-to-point interface 

The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


About OSPF Interfaces | 38 


Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
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| intra-area-prefix 


Syntax 


intra-area-prefix; 


Hierarchy Level 


[edit logical-systems name protocols ospf3 overload], 
[edit protocols ospf3 overload] 


Release Information 
Statement introduced in Junos OS Release 18.2 for MX Series Routers. 


Description 


Advertise intra-area Prefix with maximum metric. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Overload Function | 222 
allow-route-leaking | 608 


stub-network | 754 





as-external | 613 
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| ipsec-sa (Protocols OSPF) 


Syntax 


ipsec-sa name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
sham-link-remote address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for OSPFv2 authentication added in Junos OS Release 8.3. 
Support for the realm statement introduced in Junos OS Release 9.2. 


Description 


Apply IPsec authentication to an OSPF interface or virtual link or to an OSPFv2 remote sham link. 


Options 


name—Name of the IPsec authentication scheme. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPFv2 Authentication | 246 

Understanding OSPFv3 Authentication | 248 

Example: Configuring IPsec Authentication for an OSPF Interface | 261 
Junos OS Administration Library 


Junos OS Services Interfaces Library for Routing Devices 
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| label-switched-path (Protocols OSPF) 


Syntax 


label-switched-path name metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit protocols ospf area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Advertise label-switched paths into OSPF as point-to-point links. 


The label-switched path is advertised in the appropriate OSPF levels as a point-to-point link and contains 
a local address and a remote address. 


Options 


name—Name of the label-switched path. 


metric—Metric value. 
Range: 1 through 65,535 
Default: 1 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Advertising Label-Switched Paths into OSPFv2 | 407 
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| Idp-stitching (Protocols OSPF) 


Syntax 


Idp-stitching; 


Hierarchy Level 


[edit protocols ospf source-packet-routing], 
[edit routing-instances name protocols ospf source-packet-routing] 


Release Information 
Statement introduced in Junos OS Release 19.1. 


Description 


Enable segment routing to LDP stitching. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LDP Mapping Server for Interoperability of Segment Routing with LDP Overview 
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| Idp-synchronization 


Syntax 


Idp-synchronization { 
disable; 


hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast 
area area-id interface interface-name], 

[edit protocols ospf area area-id interface interface-namel], 

[edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name] 


Release Information 

Statement introduced in Junos OS Release 7.5. 

Support for the realm statement introduced in Junos OS Release 9.2. Only the ipv4-unicast option is 
supported with this statement. 


Description 


Enable synchronization by advertising the maximum cost metric until LDP is operational on the link. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Synchronization Between LDP and OSPF | 234 
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link-protection (Protocols OSPF) 


Syntax 


link-protection; 


Hierarchy Level 


[edit protocols (ospf | ospf3) area area-name interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-name interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-name interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area 
area-name interface interface-name], 

[edit protocols ospf3 realm ipv4-unicast area area-id], 

[edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id], 

[edit protocols ospf area area-id interface interface-name topology (default | name)], 

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (default | 
name)], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (default 
| name)] 


Release Information 
Statement introduced in Junos OS Release 10.0. 


Description 
Enable link protection on the specified OSPF interface. Junos OS creates a backup loop-free alternate 
path to the primary next hop for all destination routes that traverse the protected interface. 


NOTE: This feature calculates alternate next hop paths for unicast routes only. Therefore, this 
statement is not supported with the OSPF IPv4 multicast topology or with the OSPFv3 IPv4 
multicast and IPv6 multicast realms. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Configuring Link Protection for OSPF | 333 
node-link-protection | 705 
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| Isa-refresh-interval 


Syntax 


Isa-refresh-interval minutes; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 
Statement introduced in Junos OS Release 12.2. 


Description 

Configure the refresh interval for all self-generated link-state advertisement (LSAs). The OSPF standard 
requires that every LSA be refreshed every 30 minutes. The Juniper Networks implementation refreshes 
LSAs every 50 minutes. By default, any LSA that is not refreshed expires after 60 minutes. By using this 
configuration, you can specify when self-originated LSAs are refreshed. 


You can override the default behavior by globally configuring the OSPF LSA refresh interval at the [edit 

protocols ospf | ospf3] hierarchy level. However, if you also have OSPF flood reduction configured for a 
specific interface in an OSPF area at the [edit protocols ospf | ospf3 area area-id interface interface-name] 
hierarchy level, the flood reduction configuration takes precedence for that specific interface. 


Options 
minutes—Time between an LSA refresh, in minutes. 
Range: 25 through 50 minutes (1,500 through 3,000 seconds) 


Default: 50 minutes 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


| Configuring OSPF Refresh and Flooding Reduction in Stable Topologies | 232 


Isp-metric-into-summary 


Syntax 


Isp-metric-into-summary; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) traffic-engineering shortcuts], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) 
traffic-engineering shortcuts], 

[edit protocols (ospf | ospf3) traffic-engineering shortcuts], 


[edit routing-instances routing-instance-name protocols (ospf | ospf3) traffic-engineering shortcuts] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches. 


Description 


Advertise the LSP metric in summary LSAs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Support for Traffic Engineering | 392 
Example: Enabling OSPF Traffic Engineering Support | 394 
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| md5 


Syntax 


md5 key-identifier { 
key key-values; 
start-time time; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name authentication], 

[edit logical-systems logical-system-name protocols ospf area area-id virtual-link authentication], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name authentication], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
virtual-link authentication], 

[edit protocols ospf area area-id interface interface-name authentication], 

[edit protocols ospf area area-id virtual-link authentication], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], 

[edit routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure an MD5 authentication key (password). 


Options 

key-identifier—MD5 key identifier. 
Range: O through 255 
Default: O 


key key-values—One or more MD5 key strings. The MD5 key values can be from 1 through 16 characters 
long. You can specify more than one key value within the list. Characters can include ASCII strings. If you 
include spaces, enclose all characters in quotation marks (“”). 


start-time time—MD5 start time. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPFv2 Authentication | 246 
Example: Configuring MD5 Authentication for OSPFv2 Exchanges | 252 
Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface | 255 
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| metric (Protocols OSPF Interface) 


Syntax 


metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (ipv4-multicast 
| name)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
sham-link-remote], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name topology (ipv4-multicast | name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf area area-id interface interface-name topology (ipv4-multicast | name)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology 
(ipv4-multicast | name)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for Multitopology Routing introduced in Junos OS Release 9.0. 

Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. 
Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Specify the cost of an OSPF interface. The cost is a routing metric that is used in the link-state calculation. 


To set the cost of routes exported into OSPF, configure the appropriate routing policy. 
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Options 
metric—Cost of the route. 
Range: 1 through 65,535 


Default: By default, the cost of an OSPF route is calculated by dividing the reference-bandwidth value by the 
bandwidth of the physical interface. Any specific value you configure for the metric overrides the default 
behavior of using the reference-bandwidth value to calculate the cost of the route for that interface. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Controlling the Cost of Individual OSPF Network Segments | 211 
Example: Configuring OSPFv2 Sham Links | 542 


Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 


Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing in Conjunction with PIM 

bandwidth-based-metrics | 620 

reference-bandwidth | 732 
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| metric-type 
Syntax 


metric-type type; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area 
area-id nssadefault-lsa], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssa default-lsa], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)] area area-id nssa default-lsa], 

[edit protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssa default-lsa], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsal, 

[edit routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area 
area-id nssa default-lsa] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Specify the external metric type for the default LSA. 
The configured metric determines the method used to compute the cost to a destination: 


e The Type 1 external metric is equivalent to the link-state metric. The path cost uses the advertised 
external path cost and the path cost to the AS boundary router (the route is equal to the sum of all 
internal costs and the external cost). 


e The Type 2 external metric uses the cost assigned by the AS boundary router (the route is equal to the 
external cost alone). By default, OSPF uses the Type 2 external metric. 


Options 
type—Metric type: 1 or 2 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
Example: Configuring OSPF Not-So-Stubby Areas | 107 


| mtu 


Syntax 


mtu bytes; 


Hierarchy Level 


[edit interfaces interface-namel, 

[edit interfaces interface-name unit logical-unit-number family family], 

[edit interfaces interface-range name], 

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family], 

[edit logical-systems logical-system-name protocols |2circuit local-switching interface interface-name backup-neighbor 
address], 

[edit logical-systems logical-system-name protocols |2circuit neighbor address interface interface-name], 

[edit logical-systems logical-system-name protocols I2circuit neighbor address interface interface-name backup-neighbor 
address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls], 

[edit protocols I2circuit local-switching interface interface-name backup-neighbor address], 

[edit protocols I2circuit neighbor address interface interface-name] 

[edit protocols I2circuit neighbor address interface interface-name backup-neighbor address], 

[edit routing-instances routing-instance-name protocols |2vpn interface interface-name], 

[edit routing-instances routing-instance-name protocols vpls], 

[edit logical-systems name protocols ospf area name interface ], 

[edit logical-systems name routing-instances name protocols ospf area name interface], 

[edit protocols ospf area name interface ], 

[edit routing-instances name protocols ospf area name interface] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for Layer 2 VPNs and VPLS introduced in Junos OS Release 10.4. 

Statement introduced in Junos OS Release 12.1X48 for PTX Series Packet Transport Routers. 
Statement introduced in Junos OS Release 12.2 for ACX Series Universal Metro Routers. 

Support at the[set interfaces interface-name unit logical-unit-number family ccc] hierarchy level introduced 
in Junos OS Release 12.3R3 for MX Series routers. 

Statement introduced in Junos OS 17.3R1 Release for MX Series Routers. 


Description 
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Specify the maximum transmission unit (MTU) size for the media or protocol. The default MTU size depends 
on the device type. Changing the media MTU or protocol MTU causes an interface to be deleted and 
added again. 


To route jumbo data packets on an integrated routing and bridging (IRB) interface or routed VLAN interface 
(RVI) on EX Series switches, you must configure the jumbo MTU size on the member physical interfaces 

of the VLAN that you have associated with the IRB interface or RVI, as well as on the IRB interface or RVI 
itself (the interface named irb or vlan, respectively). 


y 
aa CAUTION: For EX Series switches, setting or deleting the jumbo MTU size on an IRB 
A interface or RVI while the switch is transmitting packets might cause packets to be 
dropped. 


NOTE: 

The MTU for an IRB interface is calculated by removing the Ethernet header overhead 
[6(DMAC)+6(SMAC)+2(EtherType)]. Because, the MTU is the lower value of the MTU configured 
on the IRB interface and the MTU configured on the IRB’s associated bridge domain IFDs or 
IFLs, the IRB MTU is calculated as follows: 


e Incase of Layer 2 IFL configured with the flexible-vlan-tagging statement, the IRB MTU is 
calculated by including 8 bytes overhead (SVLAN+CVLAN). 


e In case of Layer 2 IFL configured with the vlan-tagging statement, the IRB MTU is calculated 
by including a single VLAN 4 bytes overhead. 
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NOTE: 

e If a packet whose size is larger than the configured MTU size is received on the receiving 
interface, the packet is eventually dropped. The value considered for MRU (maximum receive 
unit) size is also the same as the MTU size configured on that interface. 


e Notall devices allow you to set an MTU value, and some devices have restrictions on the range 
of allowable MTU values. You cannot configure an MTU for management Ethernet interfaces 
(fxpO, em0, or meO) or for loopback, multilink, and multicast tunnel devices. 


e On ACX Series routers, you can configure the protocol MTU by including the mtu statement 
at the [edit interfaces interface-name unit logical-unit-number family inet] or [edit interfaces 
interface-name unit logical-unit-number family inet6] hierarchy level. 


e If you configure the protocol MTU at any of these hierarchy levels, the configured value is 
applied to all families that are configured on the logical interface. 


e If you are configuring the protocol MTU for both inet and inet6 families on the same logical 
interface, you must configure the same value for both the families. It is not recommended 
to configure different MTU size values for inet and inet6 families that are configured on the 
same logical interface. 


Starting in Release 14.2, MTU for IRB interfaces is calculated by removing the Ethernet header 
overhead (6(DMAC)+6(SMAC)+2(EtherType)), and the MTU is a minimum of the two values: 


e Configured MTU 
e Associated bridge domain's physical or logical interface MTU 


e For Layer 2 logical interfaces configured with flexible-vlan-tagging, IRB MTU is calculated 
by including 8 bytes overhead (SVLAN+CVLAN). 


e For Layer 2 logical interfaces configured with vlan-tagging, IRB MTU is calculated by 
including single VLAN 4 bytes overhead. 


NOTE: Changing the Layer 2 logical interface option from vlan-tagging to 
flexible-vilan-tagging or vice versa adjusts the logical interface MTU by 4 bytes 
with the existing MTU size. As a result, the Layer 2 logical interface is deleted and 
re-added, and the IRB MTU is re-computed appropriately. 


For more information about configuring MTU for specific interfaces and router or switch combinations, 
see Configuring the Media MTU. 
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Options 
bytes—MTU size. 


Range: 256 through 9192 bytes, 256 through 9216 (EX Series switch interfaces), 256 through 9500 bytes 
(Junos OS 12.1X48R2 for PTX Series routers), 256 through 9500 bytes (Junos OS 16.1R1 for MX Series 
routers) 


NOTE: Starting in Junos OS Release 16.1R1, the MTU size for a media or protocol is increased from 
9192 to 9500 for Ethernet interfaces on the following MX Series MPCs: 


e MPC1 
e MPC2 
e MPC2E 
MPC3E 


MPC4E 


MPC5E 


MPC6E 


Default: 1500 bytes (INET, INET6, and ISO families), 1448 bytes (MPLS), 1514 bytes (EX Series switch interfaces) 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Media MTU 
Configuring the MTU for Layer 2 Interfaces 
Setting the Protocol MTU 
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neighbor (Protocols OSPF) 


Syntax 


neighbor address <eligible>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

For nonbroadcast interfaces only, specify neighboring routers. On a nonbroadcast interface, you must 
specify neighbors explicitly because OSPF does not send broadcast packets to dynamically discover their 
neighbors. To specify multiple neighbors, include multiple neighbor statements. 


Options 


address—IP address of a neighboring router. 


eligible—(Optional) Allow the neighbor to become a designated router. 


Default: If you omit this option, the neighbor is not considered eligible to become a designated router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


About OSPF Interfaces | 38 


Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
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network-summary-export 


Syntax 


network-summary-export policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit protocols ospf area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced in Junos OS Release 9.1. 


Description 
Apply an export policy that specifies which network-summary link-state advertisements (LSAs) are flooded 
into an OSPF v2 area. 


Options 
policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term 
term-name] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Import and Export Policies for Network Summaries Overview | 505 
Example: Configuring an OSPF Export Policy for Network Summaries | 505 


network-summary-import | 692 





Routing Policies, Firewall Filters, and Traffic Policers User Guide 
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network-summary-import 


Syntax 


network-summary-import policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit protocols ospf area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced in Junos OS Release 9.1. 


Description 
Apply an import policy that specifies which routes learned from an OSPFv2 area are used to generate 
network-summary link-state advertisements to other areas. 


Options 
policy-name—Name of a policy configured at the [edit policy-options policy-statement policy-name term 
term-name] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Import and Export Policies for Network Summaries Overview | 505 
Example: Configuring an OSPF Import Policy for Network Summaries | 516 


network-summary-export | 691 





Routing Policies, Firewall Filters, and Traffic Policers User Guide 
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| no-advertise-adjacency-segment (Protocols OSPF) 


Syntax 


no-advertise-adjacency-segment; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area nameinterface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area nameinterface 
interface-name], 

[edit protocols ospf area nameinterface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area name interface interface-name], 


Release Information 

Statement introduced in Junos OS Release 16.2 for MX Series and PTX Series. 

Statement introduced in Junos OS Release 17.2R1 for QFX5100 and QFX10000 switches. 
Statement introduced in Junos OS Release 17.3R1 for QFX5110 and QFX5200 switches. 


Description 


Disable advertising of the adjacency segment for the specified interface. 


Default 
Enabled 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Overview | 23 


source-packet-routing 
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| no-domain-vpn-tag 
Syntax 


no-domain-vpn-tag; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 
[edit routing-instances routing-instance-name protocols (ospf | ospf3)] 


Release Information 
Statement introduced in Junos OS Release 10.3. 


Description 


Disable the virtual private network (VPN) tag for OSPFv2 and OSPF v3 external routes generated by the 
provider edge (PE) router when the VPN tag is no longer needed. 


Options 


None. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routing Between PE and CE Routers in Layer 3 VPNs 
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| no-eligible-backup (Protocols OSPF) 


Syntax 


no-eligbile-backup; 


Hierarchy Level 


[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast 
area area-id interface interface-name], 

[edit protocols ospf area area-id interface interface-name topology (default | name)], 

[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name topology (default | 
name)], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name topology (default 
| name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name topology (default | name)], 


Release Information 
Statement introduced in Junos OS Release 10.0. 


Description 


Exclude the specified interface as a backup interface for OSPF interfaces on which link protection or 
node-link protection is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Excluding an OSPF Interface as a Backup for a Protected Interface | 337 
link-protection | 676 
node-link-protection | 705 
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| no-interface-state-traps 


Syntax 


no-interface-state-traps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit protocols ospf area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], 


Release Information 
Statement introduced in Junos OS Release 10.3. 


Description 
Disable the OSPF traps for interface state changes. This statement is particularly useful for OSPF interfaces 
in passive mode. 


NOTE: The no-interface-state-traps statement is supported only for OSPFv2. 


Default 


This statement is disabled by default. You must include the no-interface-state-traps statement to disable 
OSPF traps for interface state changes. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring a Passive OSPF Interface | 46 
passive | 714 
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| no-neighbor-down-notification 
Syntax 


no-neighbor-down-notification; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], 
[edit protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 8.0. 


Description 


Disable neighbor down notification for OSPF to allow for migration from OSPF to IS-IS without disruption 
of the RSVP neighbors and associated RSVP-signaled LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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| no-nssa-abr 


Syntax 


no-nssa-abr; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced in Junos OS Release 7.6. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Disable exporting Type 7 link-state advertisements into not-so-stubby-areas (NSSAs) for an autonomous 
system boundary router (ASBR) or an area border router (ABR). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Not-So-Stubby Areas | 107 
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| no-rfc-1583 
Syntax 


no-rfc-1583; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast)] 


Release Information 

Statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 

Disable compatibility with RFC 1583, OSPF Version 2. If the same external destination is advertised by AS 
boundary routers that belong to different OSPF areas, disabling compatibility with RFC 1583 can prevent 
routing loops. 


Default 
Compatibility with RFC 1583 is enabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control-level—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Disabling OSPFv2 Compatibility with RFC 1583 | 239 
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| no-source-packet-routing (Protocols OSPF) 


Syntax 


no-source-packet-routing; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf backup-spf-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf backup-spf-options], 
[edit protocols ospf backup-spf-options], 

[edit routing-instances routing-instance-name protocols ospf backup-spf-options] 


Release Information 

Statement introduced in Junos OS Release 16.2 for MX Series. 

Statement introduced in Junos OS Release 17.2R1 for QFX10000 and QFX5100 switches. 
Statement introduced in Junos OS Relese 17.3R1 for QFX5110 and QFX5200 switches. 


Description 
Disables use of source packet routing node segment labels for computing backup paths for normal IPv4 
OSPF prefixes and OSPF source packet routing node segments. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Overview | 23 
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| no-strict-lsa-checking 
Syntax 


no-strict-Isa-checking; 


Hierarchy Level 


[edit protocols (ospf | ospf3) graceful-restart] 


Release Information 

Statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 12.1 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Disable strict OSPF link-state advertisement (LSA) checking to prevent the termination of graceful restart 
by a helping router or switch. 


Default 
By default, LSA checking is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Graceful Restart Options for OSPF and OSPFv3 
Configuring Graceful Restart for QFabric Systems 


maximum-neighbor-recovery-time 





recovery-time 
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| node (Protocols OSPF or OSPF3) 


Syntax 


node { 
exclude [ node-address ]; 
preference [ node-address ]; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances instance-name routing-options backup-selection destination 
prefix interface interface-name], 

[edit logical systems logical-system-name routing-options backup-selection destination prefix interface interface 
name], 

[edit routing-instances instance-name routing-options backup-selection destination prefix interface interface-name], 

[edit routing-options backup-selection destination prefix interface interface name] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 

Define a list of loop-back IP addresses of the adjacent nodes to either prefer or exclude in the backup path 
selection. The node can be a local (adjacent router) node, remote node, or any other router in the backup 
path. 


NOTE: The nodes are identified through the route-id advertised by a node in the LSP. 


Options 
exclude [ node-address |— Specify one or more nodes to be excluded. The backup path that has a router 
from the list is not selected as the loop-free alternative or backup next hop. 


preference [ node-address ]— Define an ordered set of one or more nodes to be preferred. The backup 
path having the leftmost node is selected. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol | 453 
Configuring Backup Selection Policy for the OSPF Protocol | 444 

Understanding Backup Selection Policy for OSPF Protocol | 442 

backup-selection (Protocols ISIS) 
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node-link-degradation (Protocols OSPF) 


Syntax 


node-link-degradation; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) backup-spf-options], 

[edit logical-systems logical-system-name protocols ospf topology (default | name) backup-spf-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) 
backup-spf-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| name) backup-spf-options], 

[edit protocols (ospf | ospf3) backup-spf-options], 

[edit protocols ospf topology (default | name) backup-spf-options], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) backup-spf-options], 

[edit routing-instances routing-instance-name protocols ospf topology (default | name) backup-spf-options] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 
Degrade to link protection when node-link protection is not available. A link protecting loop-free alternate 
(LFA) is used when node-link protecting LFA is not available in the topology for any of the protected links. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control-level—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Backup SPF Options for Protected OSPF Interfaces | 338 
link-protection | 676 
node-link-protection | 705 
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node-link-protection (Protocols OSPF) 


Syntax 


node-link-protection; 


Hierarchy Level 


[edit protocols (ospf | ospf3) protocols area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm ipv4-unicast 
area area-id interface interface-name], 


Release Information 
Statement introduced in Junos OS Release 10.0. 


Description 

Enable node-link protection on the specified OSPF interface. Junos OS creates an alternate loop-free path 
to the primary next hop for all destination routes that traverse a protected interface. This alternate path 
avoids the primary next-hop router altogether and establishes a path through a different router. 


NOTE: This feature is not supported for the OSPF IPv4 multicast topology or for the OSPFv3 
IPv4 multicast or IPv6 multicast topologies because node-link protection creates alternate 
next-hop paths only for unicast routes. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Node-Link Protection for OSPF | 335 
link-protection | 676 
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| node-segment (Protocols OSPF) 


Syntax 


node-segment { 
ipv4-index index; 
index-range index range; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf source-packet-routing], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf 
source-packet-routing], 

[edit protocols ospf source-packet-routing], 

[edit routing-instances routing-instance-name protocols ospf source-packet-routing] 


Release Information 

Statement introduced in Junos OS Release 16.2 for MX Series. 

Statement introduced in Junos OS Release 17.2R1 for QFX5100 and QFX10000 switches. 
Statement introduced in Junos OS Release 17.3R1 for QFX5110 and QFX5200 switches. 


Description 

Enable source packet routing in networking (SPRING) at all levels. SPRING, or segment routing, is a 
control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes 
and links in the network without relying on the intermediate nodes in the network to determine the actual 
path it should take. 


NOTE: You can provision an IPv4 node segment index for a routing instance, not for a specific 
OSPF area. A node segment index is attached to the IPv4 router-id, if the router-ids are configured 
on the loopback interface. Otherwise, the lowest IP address on the loopback interface is chosen 
to attach the node segment identifier.. 


Options 

index-range index range— Range of node segment indices allowed. 
Default: 4096 
Range: 32 through 4096 


ipv4-index index— IPv4 node segment index. 
Range: O through 4095 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Overview | 23 
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notify-duration 


Syntax 


notify-duration seconds; 


Hierarchy Level 


[edit protocols (ospf | ospf3) graceful-restart], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) graceful-restart], 

[edit logical-systems logical-system-name routing-instances instance-name protocols (ospf | ospf3) graceful-restart], 
[edit routing-instances instance-name protocols (ospf | ospf3) graceful-restart] 


Release Information 

Statement introduced in Junos OS Release 8.3. 

Statement introduced in Junos OS Release 12.1 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Specify the length of time the router or switch notifies helper OSPF routers that it has completed graceful 
restart. 


Options 

seconds—Length of time in the router notifies helper OSPF routers that it has completed graceful restart. 
Range: 1 through 3600 
Default: 30 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Graceful Restart Options for OSPF and OSPFv3 
Configuring Graceful Restart for QFabric Systems 


restart-duration 
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| nssa 


Syntax 


nssa { 
area-range network/mask-length <restrict> <exact> <override-metric metric>; 
default-lIsa { 
default-metric metric; 
metric-type type; 
type-7; 
} 


(no-summaries | summaries); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3) area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Configure a not-so-stubby area (NSSA). An NSSA allows external routes to be flooded within the area. 
These routes are then leaked into other areas. 


You cannot configure an area as being both a stub area and an NSSA. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
Example: Configuring OSPF Not-So-Stubby Areas | 107 
stub | 753 


| ospf 
Syntax 


ospf {... } 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols], 
[edit protocols], 

[edit routing-instances routing-instance-name protocols] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Enable OSPF routing on the routing device. 


You must include the ospf statement to enable OSPF on the routing device. 


Default 
OSPF is disabled on the routing device. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Configurations | 35 
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ospf3 
Syntax 


ospf3 {... } 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols], 
[edit protocols], 

[edit routing-instances routing-instance-name protocols] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 


Description 


Enable OSPFv3 routing on the routing device. 


You must include the ospf3 statement to enable OSPF v3. 


Default 
OSPFv3 is disabled on the routing device. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Configurations | 35 
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| overload (Protocols OSPF) 


Syntax 


overload { 
timeout seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (oospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| ipv4-multicast | name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf topology (default | ipv4-multicast | name)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for Multitopology Routing introduced in Junos OS Release 9.0. 

Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. 
Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Configure the local routing device so that it appears to be overloaded. You might do this when you want 
the routing device to participate in OSPF routing, but do not want it to be used for transit traffic. 


NOTE: Traffic destined to directly attached interfaces continues to reach the routing device. 
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Options 
timeout seconds—(Optional) Number of seconds at which the overloading is reset. If no timeout interval 


is specified, the routing device remains in overload state until the overload statement is deleted or a 
timeout is set. 


Range: 60 through 1800 seconds 


Default: O seconds 


The timeout is configured with a prefix-limit. If the number of prefixes exceeds the configured limit, the 
overload state is reached. The routing device remains in the overload state even though the prefixes have 
been reduced under the limit. Therefore, you need to clear the overload state using the clear (ospf | ospf3) 
overload command. 


NOTE: Multitopology Routing does not support the timeout option. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF to Make Routing Devices Appear Overloaded | 224 
Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 


Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 
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| passive (Protocols OSPF) 


Syntax 


passive { 
traffic-engineering { 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

traffic-engineering and remote-node-id address statements introduced in Junos OS Release 8.0. 
traffic-engineering and remote-node-id address statements introduced in Junos OS Release 8.0 for EX 
Series switches. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 

Advertise the direct interface addresses on an interface without actually running OSPF on that interface. 
A passive interface is one for which the address information is advertised as an internal route in OSPF, 
but on which the protocol does not run. 


To configure an interface in OSPF passive traffic engineering mode, include the traffic-engineering 
statement. Configuring OSPF passive traffic engineering mode enables the dynamic discovery of OSPF 
AS boundary routers. 


Enable OSPF on an interface by including the interface statement at the [edit protocols (ospf | ospf3) area 
area-id] or the [edit routing-instances routing-instance-name protocols ospf area area-id] hierarchy levels. 


Disable it by including the disable statement, To prevent OSPF from running on an interface, include the 
passive statement. These three states are mutually exclusive. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring a Passive OSPF Interface | 46 
Example: Configuring OSPF Passive Traffic Engineering Mode | 403 
disable | 638 
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| peer-interface (Protocols OSPF) 


Syntax 


peer-interface interface-name { 
disable; 
dead-interval seconds; 
hello-interval seconds; 
retransmit-interval seconds; 
transit-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id], 
[edit protocols ospf area area-id] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure a peer interface. 


Options 


interface-name—Name of the peer interface. To configure all interfaces, you can specify all. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPFv2 Peer interfaces | 49 
Configuring RSVP and OSPF for LMP Peer Interfaces 
Configuring a Hierarchy of RSVP LSPs to Tunnel Multiple RSVP LSPs Over a Single RSVP LSP 
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| per-prefix-calculation 


Syntax 


per-prefix-calculation { 
all; 
externals; 
stub; 
summary; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) backup-spf-options], 

[edit logical-systems logical-system-name protocols ospf topology (default | name) backup-spf-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) 
backup-spf-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| name) backup-spf-options], 

[edit protocols (ospf | ospf3) backup-spf-options], 

[edit protocols ospf topology (default | name) backup-spf-options], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) backup-spf-options], 

[edit routing-instances routing-instance-name protocols ospf topology (default | name) backup-spf-options] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Calculate backup nexthops for non-best prefix originators. 


Options 


all—Calculate per-prefix loop free alternate (LFA) for all. 
externals—Calculate per-prefix LFA for not-so-stubby and externals only. 
stubs—Calculate per-prefix LFA for stubs only. 


summary—Calculate per-prefix LFA for summary originators only. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control-level—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring Backup SPF Options for Protected OSPF Interfaces | 338 
link-protection | 676 
node-link-protection | 705 
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| poll-interval 


Syntax 


poll-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
For nonbroadcast interfaces only, specify how often the router sends hello packets out of the interface 
before it establishes adjacency with a neighbor. 


Options 

seconds—Frequency at which to send hello packets. 
Range: 1 through 255 seconds 
Default: 120 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Timers Overview | 282 


Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network | 51 
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| post-convergence-lIfa (Protocols OSPF) 


Syntax 


post-convergence-lfa <node-protection <cost cost>; 


Hierarchy Level 


[edit logical-systems name protocols ospf area interface interface-name ], 

[edit logical-systems name routing-instances name protocols ospf area interface interface-name], 
[edit protocols ospf area interface interface-name ], 

[edit routing-instances name protocols ospf area interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 18.2R1 for MX Series, PTX Series, and QFX Series. 


Description 
Configure the installation of backup-paths that follow the post-convergence paths corresponding to the 
failure of this interface. 


Options 
node-protection—Enable node protection mode for topology-independent loop-free alternate (TI-LFA) 
routes for OSPF. 


cost—Enable a node-protecting post-convergence backup path to be computed for all primary next-hops 
using this interface. Configure the cost of all the links used for calculating the TI-LFA 
post-convergence failure path cost. If node protection is enabled without configuring a cost value, 
then the cost is set to the maximum cost or default value of 65535. 


Default: 65535 
Range: 1 through 65535 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


use-post-convergence-lfa | 774 


Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 450 
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| preference (Protocols OSPF) 


Syntax 


preference preference; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Set the route preference for OSPF internal routes. 


Options 

preference—Preference value. 
Range: 0 through 4,294,967,295 (2°* - 1) 
Default: 10 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Controlling OSPF Route Preferences | 220 
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external-preference | 644 
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| prefix-export-limit (Protocols OSPF) 


Syntax 


prefix-export-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| ipv4-multicast | name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf topology (default | ipv4-multicast | name)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for Multitopology Routing introduced in Junos OS Release 9.0. 

Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. 
Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure a limit to the number of prefixes exported into OSPF. 


Options 

number—Prefix limit. 
Range: 0 through 4,294,967,295 (2°* - 1) 
Default: None 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Limiting the Number of Prefixes Exported to OSPF | 207 


Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 


Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 





Understanding Multitopology Routing in Conjunction with PIM 
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| priority (Protocols OSPF) 


Syntax 


priority number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 

Specify the routing device's priority for becoming the designated routing device. The routing device that 
has the highest priority value on the logical IP network or subnet becomes the network’s designated router. 
You must configure at least one routing device on each logical IP network or subnet to be the designated 
router. You also should specify a routing device's priority for becoming the designated router on 
point-to-point interfaces. 


Options 
number—Routing device's priority for becoming the designated router. A priority value of O means that 
the routing device never becomes the designated router. A value of 1 means that the routing device has 
the least chance of becoming a designated router. 

Range: O through 255 

Default: 128 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Designated Router Overview | 68 
Example: Controlling OSPF Designated Router Election | 71 
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| protocols 


Syntax 


protocols { 
bgp { 
... bgp-configuration ... 
} 
isis { 
... isis-configuration ... 
} 
Idp { 
... Idp-configuration ... 
} 
mpls { 
... mpls -configuration ... 
} 
msdp { 
... msdp-configuration ... 
} 
mstp { 
... mstp-configuration ... 
} 
ospf { 
domain-id domain-id; 
domain-vpn-tag number; 
route-type-community (iana | vendor); 
traffic-engineering { 
<advertise-unnumbered-interfaces>; 
<credibility-protocol-preference>; 
ignore-Isp-metrics; 
multicast-rpf-routes; 
no-topology; 
shortcuts { 
Isp-metric-into-summary; 


... ospf-configuration ... 

} 

ospf3 { 
domain-id domain-id; 
domain-vpn-tag number; 
route-type-community (iana | vendor); 
traffic-engineering { 

<advertise-unnumbered-interfaces>; 
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<credibility-protocol-preference>; 

ignore-Isp-metrics; 

multicast-rpf-routes; 

no-topology; 

shortcuts { 
Isp-metric-into-summary; 


} 
... ospf3-configuration ... 
} 
pim { 
... pim-configuration ... 
} 
rip { 
... rip-configuration ... 
} 
ripng { 
... ripng-configuration ... 
} 
rstp { 
rstp-configuration; 
} 
rsvpf{ 
... rsvp-configuration ... 
} 
vstp { 
vstp configuration; 
} 
vpls { 
vpls configuration; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name], 
[edit routing-instances routing-instance-name] 
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Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for RIPng introduced in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

mpls and rsvp options added in Junos OS Release 15.1. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Specify the protocol for a routing instance. You can configure multiple instances of many protocol types. 
Not all protocols are supported on the switches. See the switch CLI. 


Options 
bgp—Specify BGP as the protocol for a routing instance. 


isis—Specify IS-IS as the protocol for a routing instance. 

Idp—Specify LDP as the protocol for a routing instance or for a virtual router instance. 
I2vpn—Specify Layer 2 VPN as the protocol for a routing instance. 

mpls—Specify MPLS as the protocol for a routing instance. 

msdp—Specify the Multicast Source Discovery Protocol (MSDP) for a routing instance. 
mstp—Specify the Multiple Spanning Tree Protocol (MSTP) for a virtual switch routing instance. 
ospf—Specify OSPF as the protocol for a routing instance. 


ospf3—Specify OSPF version 3 (OSPF v3) as the protocol for a routing instance. 


NOTE: OSPFv3 supports the no-forwarding, virtual-router, and vrf routing instance types only. 


pim—Specify the Protocol Independent Multicast (PIM) protocol for a routing instance. 
rip—Specify RIP as the protocol for a routing instance. 

ripng—Specify RIP next generation (RIPng) as the protocol for a routing instance. 
rstp—Specify the Rapid Spanning Tree Protocol (RSTP) for a virtual switch routing instance. 
rsvp—Specify the RSVP for a routing instance. 

vstp—Specify the VLAN Spanning Tree Protocol (VSTP) for a virtual switch routing instance. 


vpls—Specify VPLS as the protocol for a routing instance. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Multiple Routing Instances of OSPF | 272 
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| realm 


Syntax 


realm (ipv4-unicast | ipv4-multicast | ipv6-unicast) { 
area area-id { 
interface interface-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf3], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3], 
[edit protocols ospf3], 

[edit routing-instances routing-instance-name protocols ospf3] 


Release Information 
Statement introduced in Junos OS Release 9.2. 
Statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Configure OSPFv3 to advertise address families other than unicast IPv6. Junos OS maps each address 
family you configure to a separate realm with its own set of neighbors and link-state database. 


Options 


ipv4-unicast—Configure a realm for IPv4 unicast routes. 
ipv4-multicast—Configure a realm for IPv4 multicast routes. 
ipv6-multicast—Configure a realm for IPv6 multicast routes. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Multiple Address Families for OSPFv3 | 58 
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| reference-bandwidth (Protocols OSPF) 


Syntax 


reference-bandwidth reference-bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 
[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Set the reference bandwidth used in calculating the default interface cost. The cost is calculated using the 
following formula: 


cost = ref-bandwidth/bandwidth 


Options 

reference-bandwidth—Reference bandwidth, in bits per second. 
Range: 9600 through 1,000,000,000,000 bits 
Default: 100 Mbps (100,000,000 bits) 


NOTE: The default behavior is to use the reference-bandwidth value to calculate the cost of 
OSPF interfaces. You can override this behavior for any OSPF interface by configuring a specific 
cost with the metric statement. 
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Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Controlling the Cost of Individual OSPF Network Segments | 211 
metric | 682 
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| remote-backup-calculation(Protocols OSPF) 


Syntax 


remote-backup-calculation; 


Hierarchy Level 


[edit protocols (ospf | ospf3) backup-spf-options], 
[edit protocols ospf topology (default | ipv4-multicast | name) backup-spf-options] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 

Determine the remote LFA backup paths from the point of local repair (PLR) in an OSPF network. For 
every protected link on the PLR, Junos OS creates a dynamic LDP label-switched path to reach the remote 
LFA node. When the primary link fails, the PLR uses these remote LFA backup paths to reach all the 
destinations reachable through the primary link. 


Required Privilege Level 


RELATED DOCUMENTATION 


Remote LFA over LDP Tunnels in OSPF Networks Overview | 368 

Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks | 371 
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network | 369 
auto-targeted-session 


backup-spf-options | 618 





no-eligible-remote-backup 
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| retransmit-interval (OSPF) 


Syntax 


retransmit-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-namel, 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how long the routing device waits to receive a link-state acknowledgment packet before 
retransmitting link-state advertisements (LSAs) to an interface’s neighbors. 


Options 
seconds—Interval to wait. 
Range: 1 through 65,535 seconds 


Default: 5 seconds 


NOTE: You must configure LSA retransmit intervals to be equal to or greater than 3 seconds to 
avoid triggering a retransmit trap, because Junos OS delays LSA acknowledgments by up to 
2 seconds. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers | 283 
Configuring RSVP and OSPF for LMP Peer Interfaces 
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| rib-group (Protocols OSPF) 


Syntax 


rib-group group-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Install routes learned from OSPF routing instances into routing tables in the OSPF routing table group. 


Options 


group-name—Name of the routing table group. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Exporting Specific Routes from One Routing Table Into Another Routing Table 
Example: Importing Direct and Static Routes Into a Routing Instance 


Understanding Multiprotocol BGP 
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interface-routes 


rib-group 


| route-type-community 


Syntax 


route-type-community (iana | vendor); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 
[edit routing-instances routing-instance-name protocols (ospf | ospf3)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 
Specify an extended community value to encode the OSPF route type. Each extended community is coded 
as an eight-octet value. This statement sets the most significant bit to either an IANA or vendor-specific 
route type. 


Options 
iana—Encode a route type with the value 0x0306. This is the default value. 


vendor—Encode the route type with the value Ox8000. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routing Between PE and CE Routers in Layer 3 VPNs 


739 


| routing-instances (Multiple Routing Entities) 


Syntax 


routing-instances routing-instance-name { ... } 


Hierarchy Level 


[edit], 
[edit logical-systems logical-system-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

remote-vtep-v6-list statement introduced in Junos OS Release 17.3 for MX Series routers with MPC and 
MIC interfaces. 


Description 

Configure an additional routing entity for a router. You can create multiple instances of BGP, IS-IS, OSPF, 
OSPF v3, and RIP for a router. You can also create multiple routing instances for separating routing tables, 
routing policies, and interfaces for individual wholesale subscribers (retailers) in a Layer 3 wholesale 
network. 


Each routing instance consist of the following: 


e Aset of routing tables 
e Aset of interfaces that belong to these routing tables 


e Aset of routing option configurations 


Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure 
a routing instance with the name my-instance, its corresponding IP unicast table is my-instance.inet.O. All 
routes for my-instance are installed into my-instance.inet.O. 


Routes are installed into the default routing instance inet.O by default, unless a routing instance is specified. 


In Junos OS Release 9.0 and later, you can no longer specify a routing-instance name of master, default, 
or bgp or include special characters within the name of a routing instance. 


In Junos OS Release 9.6 and later, you can include a slash (/) in a routing-instance name only if a logical 
system is not configured. That is, you cannot include the slash character in a routing-instance name if a 


logical system other than the default is explicitly configured. Routing-instance names, further, are restricted 
* 


from having the form (beginning and ending with underscores). The colon : character cannot be 


used when multitopology routing (MTR) is enabled. 


Default 


Routing instances are disabled for the router. 


Options 
routing-instance-name——Name of the routing instance. This must be a non-reserved string of not more 
than 128 characters. 


remote-vtep-list—Configure static remote VXLAN tunnel endpoints. 


remote-vtep-v6-list—Configure static IPv6 remote VXLAN tunnel endpoints. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Interprovider Layer 3 VPN Option A 
Example: Configuring Interprovider Layer 3 VPN Option B 
Example: Configuring Interprovider Layer 3 VPN Option C 
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| secondary (Protocols OSPF) 


Syntax 


secondary; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit protocols ospf area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 9.2. 


Description 


Configure an interface to belong to another OSPF area. A logical interface can be configured as primary 
interface only for one area. For any other area for which you configure the interface, you must configure 
it as a secondary interface. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


interface | 660 
Example: Configuring Multiarea Adjacency for OSPF | 84 
interface | 660 
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| sham-link 
Syntax 


sham-link { 
local address; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], 
[edit routing-instances routing-instance-name protocols ospf] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure the local endpoint of a sham link. 


You can create an intra-area link or sham link between two provider edge (PE) routing devices so that the 
VPN backbone is preferred over the back-door link. A back-door link is a backup link that connects customer 
edge (CE) devices in case the VPN backbone is unavailable. When such a backup link is available and the 
CE devices are in the same OSPF area, the default behavior is to prefer this backup link over the VPN 
backbone. This is because the backup link is considered an intra-area link, while the VPN backbone is 
always considered an inter-area link. Intra-area links are always preferred over inter-area links. 


The sham link is an unnumbered point-to-point intra-area link between PE devices. When the VPN backbone 
has a sham intra-area link, this sham link can be preferred over the backup link if the sham link has a lower 
OSPF metric than the backup link. 


The sham link is advertised using Type 1 link-state advertisements (LSAs). Sham links are valid only for 
routing instances and OSPF v2. 


Each sham link is identified by the combination of a local endpoint address and a remote endpoint address. 


Options 


local address—The address for the local endpoint of the sham link. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration 


RELATED DOCUMENTATION 
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Example: Configuring OSPFv2 Sham Links | 542 


sham-link-remote | 744 
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| sham-link-remote 


Syntax 


sham-link-remote address { 
demand-circuit; 
ipsec-sa name; 
metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Support for ipsec-sa statement added in Junos OS Release 8.3. 


Description 


Configure the remote endpoint of a sham link. 


You can create an intra-area link or sham link between two provider edge (PE) routing devices so that the 
VPN backbone is preferred over the back-door link. A back-door link is a backup link that connects customer 
edge (CE) devices in case the VPN backbone is unavailable. When such a backup link is available and the 
CE devices are in the same OSPF area, the default behavior is to prefer this backup link over the VPN 
backbone. This is ecause the backup link is considered an intra-area link, while the VPN backbone is always 
considered an inter-area link. Intra-area links are always preferred over inter-area links. 


The sham link is an unnumbered point-to-point intra-area link between PE devices. When the VPN backbone 
has a sham intra-area link, this sham link can be preferred over the backup link if the sham link has a lower 
OSPF metric than the backup link. 


The sham link is advertised using Type 1 link-state advertisements (LSAs). Sham links are valid only for 
routing instances and OSPFv2. 


Each sham link is identified by the combination of a local endpoint address and a remote endpoint address. 


Options 


address—Address for the remote end point of the sham link. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPFv2 Sham Links | 542 
sham-link | 742 
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| shortcuts (Protocols OSPF) 


Syntax 


shortcuts { 
Isp-metric-into-summary; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) traffic-engineering], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) 
traffic-engineering], 

[edit protocols (ospf | ospf3) traffic-engineering], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)traffic-engineering] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches. 


Description 


Configure OSPF to use MPLS label-switched paths (LSPs) as shortcut next hops. By default, shortcut routes 
calculated through OSPF v2 are installed in the inet.3 routing table, and shortcut routes calculated through 
OSPF v3 are installed in the inet6.3 routing table. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Enabling OSPF Traffic Engineering Support | 394 
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| simple-password 
Syntax 


simple-password key; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name authentication], 

[edit logical-systems logical-system-name protocols ospf area area-id virtual-link authentication], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name authentication], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
virtual-link authentication], 

[edit protocols ospf area area-id interface interface-name authentication], 

[edit protocols ospf area area-id virtual-link authentication], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name authentication], 

[edit routing-instances routing-instance-name protocols ospf area area-id virtual-link authentication] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure a simple authentication key (password). 


Options 


key—Password string. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPFv2 Authentication | 246 
Example: Configuring Simple Authentication for OSPFv2 Exchanges | 249 
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| source-packet-routing-enable (Protocols OSPF) 


Syntax 


source-packet-routing { 

adjacency-segment { 
hold-time hold-time; 

} 

disable; 

explicit-null; 

node-segment { 
index-range index range; 
ipv4-index index; 

} 

srgb { 
start-label start-label; 


index-range index range; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], 
[edit protocols ospf], 

[edit routing-instances routing-instance-name protocols ospf] 


Release Information 
Statement introduced in Junos OS Release 16.2. 
Statement introduced in Junos OS Release 17.2R1 for QFX5100, QFX5110, and QFX10000 switches. 


Description 


Enable source packet routing in networking (SPRING) feature. 


The remaining statements are explained separately. See CLI Explorer. 


Default 


Disabled on all the levels. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


749 


RELATED DOCUMENTATION 


| OSPF Overview | 23 


source-packet-routing-disable (Protocols OSPF) 


Syntax 


source-packet-routing { 
disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf areaarea-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit protocols ospf area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced in Junos OS Release 16.2 for MX and PTX Series. 


Description 


Disable source packet routing in networking (SPRING) feature for a specific OSPF area. 


Default 


Enabled, if source-packet-routing is configured globally at: 


[edit logical-systems logical-system-name protocols ospf], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], 
[edit protocols ospf], 

[edit routing-instances routing-instance-name protocols ospf] 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


OSPF Overview | 23 
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| spf-options (Protocols OSPF) 


Syntax 


spf-options { 
delay milliseconds; 
holddown milliseconds; 


rapid-runs number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf topology (default | ipv4-multicast | name)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf topology (default 
| ipv4-multicast | name)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf topology (default | ipv4-multicast | name)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf topology (default | ipv4-multicast | name)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for Multitopology Routing introduced in Junos OS Release 9.0. 

Support for Multitopology Routing introduced in Junos OS Release 9.0 for EX Series switches. 
Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 


Description 


Configure options for running the shortest-path-first (SPF) algorithm. You can configure the following: 


e A delay for when to run the SPF algorithm after a network topology change is detected. 


e The maximum number of times the SPF algorithm can run in succession. 
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e Ahold-down interval after the SPF algorithm runs the maximum number of times. If the network stabilizes 
during the holddown period and the SPF algorithm does not need to run again, the system reverts to 
the configured values for the delay and rapid-runs statements. 


Running the SPF algorithm is usually the beginning of a series of larger system-wide events. For example, 
the SPF algorithm can lead to interior gateway protocol (IGP) prefix changes, which then lead to BGP 
nexthop resolution changes. Consider what happens if there are rapid link changes in the network. The 
local routing device can become overwhelmed. This is why it sometimes makes sense to throttle the 
scheduling of the SPF algorithm. 


Options 
delay milliseconds—Time interval between the detection of a topology change and when the SPF algorithm 
runs. 

Range: 50 through 8000 milliseconds 

Default: 200 milliseconds 


holddown milliseconds—Time interval to hold down, or to wait before a subsequent SPF algorithm runs 
after the SPF algorithm has run the configured maximum number of times in succession. 


Range: 2000 through 20,000 milliseconds 
Default: 5000 milliseconds 


rapid-runs number—Maximum number of times the SPF algorithm can run in succession. After the maximum 
is reached, the hold down interval begins. 

Range: 1 through 10 

Default: 3 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring SPF Algorithm Options for OSPF | 229 


Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 


Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing in Conjunction with PIM 





752 


| strict-bfd (Protocols OSPF) 


Syntax 


strict-bfd; 


Hierarchy Level 


[edit logical-systems name protocols ospf area name interface], 

[edit logical-systems name routing-instances name protocols ospf area name interface], 

[edit logical-systems name tenants name routing-instances name protocols ospf area name interface], 
[edit protocols ospf area name interface], 

[edit routing-instances name protocols ospf area name interface], 

[edit tenants name routing-instances name protocols ospf area name interface] 


Release Information 
Statement introduced in Junos OS Release 19.4 


Description 


Enable strict-bfd over an interface for OSPF. 


Required Privilege Level 
routing 
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| stub 


Syntax 


stub <default-metric metric> <(no-summaries | summaries)>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area 
area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3) area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify that this area not be flooded with AS external link-state advertisements (LSAs). You must include 
the stub statement when configuring all routing devices that are in the stub area. 


The backbone cannot be configured as a stub area. 


You cannot configure an area to be both a stub area and a not-so-stubby area (NSSA). 


Options 
no-summaries—(Optional) Do not advertise routes into the stub area. If you include the default-metric 
option, only the default route is advertised. 


summaries—(Optional) Flood summary LSAs into the stub area. 


The remaining statement is explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
Example: Configuring OSPF Stub and Totally Stubby Areas | 102 
nssa | 709 


| stub-network 


Syntax 


stub-network; 


Hierarchy Level 


[edit logical-systems name protocols ospf overload], 

[edit logical-systems name routing-instances name protocols ospf overload], 
[edit protocols ospf overload], 

[edit routing-instances name protocols ospf overload] 


Release Information 
Statement introduced in Junos OS Release 18.2 for MX Series Routers. 


Description 


Advertise Stub Network with maximum metric. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Overload Function | 222 
allow-route-leaking | 608 
intra-area-prefix | 670 


as-external | 613 
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| summaries 


Syntax 


(summaries | no-summaries); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id nssal], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssal], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id nssal, 

[edit protocols (ospf | ospf3) area area-id nssal, 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id nssal, 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssal], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id nssa] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Configure whether or not area border routers advertise summary routes into an not-so-stubby area (NSSA): 


e summaries—Flood summary link-state advertisements (LSAs) into the NSSA. 


e no-summaries—Prevent area border routers from advertising summaries into an NSSA. If default-metric 
is configured for an NSSA, a Type 3 LSA is injected into the area by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
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Example: Configuring OSPF Not-So-Stubby Areas | 107 
nssa | 709 
stub | 753 


| te-metric (Protocols OSPF) 


Syntax 


te-metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], 
[edit protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Metric value used by traffic engineering for information injected into the traffic engineering database. The 
value of the traffic engineering metric does not affect normal OSPF forwarding. 


Options 

metric—Metric value. 
Range: 1 through 65,535 
Default: Value of the IGP metric 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface | 401 


757 


| topology (OSPF) 


Syntax 


topology (default | ipv4-multicast | name) { 
spf-options { 
delay milliseconds; 
holddown milliseconds; 
rapid-runs number; 


} 


topology-id number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf], 
[edit protocols ospf], 

[edit routing-instances routing-instance-name protocols ospf] 


Release Information 

Statement introduced in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Enable a topology for OSPF multitopology routing. You must first configure one or more topologies under 
the [edit routing-options] hierarchy level. 


Options 

default—Name of the default topology. This topology is automatically created, and all routes that correspond 
to it are automatically added to the inet.0 routing table. You can modify certain default parameters, such 
as for the SPF algorithm. 


ipv4-multicast—Name of the topology for IPv4 multicast traffic. 


name—Name of a topology you configured at the [edit routing-options] hierarchy level to create a topology 
for a specific type of traffic, such as voice or video. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 

Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 

Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 


Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 
Understanding Multitopology Routing in Conjunction with PIM 
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| topology (OSPF Interface) 


Syntax 


topology (ipv4-multicast | name) { 
metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit protocols ospf area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 9.0. 


Description 
Configure interface-specific properties for multitopology OSPF, including topology-specific metric values 
for an interface. 


All OSPF interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes 
with lower total path metrics are preferred over those with higher path metrics. The default value for the 
OSPF metric for an interface is 1. You can modify the default value for an OSPF interface and configure 
a topology-specific metric for that interface. The topology-specific metric applies to routes advertised 
from the interface that belong only to that topology. 


Default 


The default value of the topology metric is the same as the default metric value calculated by OSPF or the 
value configured for the OSPF metric. 


Options 


ipv4-multicast—Name of the topology for IPv4 multicast traffic. 
name—Name of a topology created under the [edit routing-options] hierarchy level. 


metric metric—Cost of a route from an OSPF interface. You can specify a metric value for a topology that 
is different from the value specified for the interface. 


Range: 1 through 65,535 
Default: 1 


Required Privilege Level 
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routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 


Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate 
Network Paths 


Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic 





Understanding Multitopology Routing in Conjunction with PIM 
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| traceoptions (Protocols OSPF) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast)], 

[edit protocols (ospf | ospf3)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure OSPF protocol-level tracing options. 


To specify more than one tracing operation, include multiple flag statements. 


NOTE: The traceoptions statement is not supported on QFabric systems. 


Default 
The default OSPF protocol-level tracing options are those inherited from the routing protocols traceoptions 
statement included at the [edit routing-options] hierarchy level. 


Options 
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disable—(Optional) Disable the tracing operation. You can use this option to disable a single operation 
when you have defined a broad group of tracing operations, such as all. 


file filename—Name of the file to receive the output of the tracing operation. Enclose the name within 
quotation marks. All files are placed in the directory /var/log. We recommend that you place OSPF tracing 
output in the file ospf-log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace 
files is reached. Then, the oldest trace file is overwritten. 
If you specify a maximum number of files, you also must specify a maximum file size with the size option. 
Range: 2 through 1000 files 
Default: 10 files 


flag flag—Tracing operation to perform. To specify more than one tracing operation, include multiple flag 
statements. 


OSPF Tracing Flags 


e database-description—Database description packets, which are used in synchronizing the OSPF and 
OSPF v3 topological database. 


error—OSPF and OSPF v3 error packets. 


event—OSPF and OSPFv3 state transitions. 


flooding—Link-state flooding packets. 


graceful-restart—Graceful-restart events. 


hello—Hello packets, which are used to establish neighbor adjacencies and to determine whether 
neighbors are reachable. 


Idp-synchronization—Synchronization events between OSPF and LDP. 


Isa-ack—Link-state acknowledgment packets, which are used in synchronizing the OSPF topological 
database. 


Isa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of OSPF, Junos OS 
performs LSA analysis before running the shortest-path-first (SPF) algorithm. LSA analysis helps to speed 
the calculations performed by the SPF algorithm. 


Isa-request—Link-state request packets, which are used in synchronizing the OSPF topological database. 


Isa-update—Link-state updates packets, which are used in synchronizing the OSPF topological database. 


nsr-synchronization—Nonstop routing synchronization events. 
e on-demand—Trace demand circuit extensions. 

e packet-dump—Content of selected packet types. 

packets—All OSPF packets. 
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e restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events. 


e spf—Shortest-path-first (SPF) calculations. 
Global Tracing Flags 


e all—All tracing operations. 


general—A combination of the normal and route trace operations. 


normal—All normal operations. If you do not specify this option, only unusual or abnormal operations 


are traced. 


policy—Policy operations and actions. 
e route—Routing table changes. 


state—State transitions. 


e task—Routing protocol task processing. 


e timer—Routing protocol timer processing. 
flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of these modifiers: 


e detail—Detailed trace information. 
e receive—Packets being received. 


e send—Packets being transmitted. 
no-world-readable—(Optional) Prevent any user from reading the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again 
reaches its maximum size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.O. This 
renaming scheme continues until the maximum number of trace files is reached. Then, the oldest trace file 
is overwritten. 
If you specify a maximum file size, you also must specify a maximum number of trace files with the files 
option. 

Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 

Range: 10 KB through the maximum file size supported on your system 

Default: 128 KB 


world-readable—(Optional) Allow any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Tracing OSPF Protocol Traffic | 594 


764 


765 


traffic-engineering (OSPF) 


Syntax 


traffic-engineering { 
<advertise-unnumbered-interfaces>; 
<credibility-protocol-preference>; 
ignore-Isp-metrics; 
multicast-rpf-routes; 
no-topology; 
igp-topology; 
shortcuts { 

Isp-metric-into-summary; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 
[edit protocols (ospf | ospf3)] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

multicast-rpf-routes option introduced in Junos OS Release 7.5. 

advertise-unnumbered-interfaces option introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4. 

Support for OSPFv3 (ospf3) introduced in Junos OS Release 9.4 for EX Series switches. 
credibility-protocol-preference statement introduced in Junos OS Release 9.4. 
credibility-protocol-preference statement introduced in Junos OS Release 9.4 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 

Support for igp-topology statement introduced in Junos OS Release 17.4R1 for MX series, and PTX Series. 


Description 


Enable the OSPF traffic engineering features. 


Default 


Traffic engineering support is disabled. 


Options 
advertise-unnumbered-interfaces—(Optional) (OSPFv2 only) Include the link-local identifier in the link-local 
traffic-engineering link-state advertisement. This statement must be included on both ends of an 
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unnumbered link to allow an ingress LER to update the link in its traffic engineering database and use it 
for CSPF calculations. The link-local identifier is then used by RSVP to signal unnumbered interfaces as 
defined in RFC 3477. 


credibility-protocol-preference—(Optional) (OSPFv2 only) Use the configured preference value for OSPF 
routes to calculate the traffic engineering database credibility value used to select IGP routes. Use this 
statement to override the default behavior, in which the traffic engineering database prefers IS-IS routes 
even if OSPF routes are configured with a lower, that is, preferred, preference value. For example, OSPF 
routes have a default preference value of 10, whereas IS-IS Level 1 routes have a default preference value 
of 15. When protocol preference is enabled, the credibility value is determined by deducting the protocol 
preference value from a base value of 512. Using default protocol preference values, OSPF has a credibility 
value of 502, whereas IS-IS has a credibility value of 497. Because the traffic engineering database prefers 
IGP routes with the highest credibility value, OSPF routes are now preferred. 


multicast-rpf-routes—(Optional) (OSPFv2 only) Install routes for multicast RPF checks into the inet.2 
routing table. The inet.2 routing table consists of unicast routes used for multicast RPF lookup. RPF is an 
antispoofing mechanism used to check whether the packet is coming in on an interface that is also sending 
data back to the packet source. 


NOTE: You must enable OSPF traffic engineering shortcuts to use the multicast-rpf-routes 
statement. You must not allow LSP advertisements into OSPF when configuring the 
multicast-rpf-routes statement. 


no-topology—(Optional) (OSPFv2 only) Disable the dissemination of the link-state topology information. 


igp-topology—Download IGP topology information into the traffic engineering database (TED). In Junos 
OS, the IGPs install topology information into a database called the traffic engineering database. The traffic 
engineering database contains the aggregated topology information. The IGP routes are installed by the 
traffic engineering database on behalf of the corresponding IGP into a user-visible routing table called 
Isdist.0, subject to route policies. 


The remaining statements are explained separately. See CLI Explorer. 
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Loe 


CAUTION: When the OSPF traffic engineering configuration is considerably modified, 
A the routing table entries are deleted and the routing table is recreated. Changes to 
configuration that can cause this behavior include enabling or disabling: 


e Traffic engineering shortcuts 
e IGP shortcuts 

e LDP tunneling 

e Multiprotocol LSP 

e Advertise summary metrics 


e Multicast RPF routes 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Enabling OSPF Traffic Engineering Support | 394 
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| traffic-engineering (Passive TE Mode) 


Syntax 


traffic-engineering { 
remote-node-id address; 
remote-node-router-id address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name passive], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name passive], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name passive], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name passive], 

[edit protocols (ospf | ospf3) area area-id interface interface-name passive], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast) area area-id interface interface-name 
passive], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name passive], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name passive] 


Release Information 

Statement introduced in Junos OS Release 8.0. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
remote-node-router-id address option introduced in Junos OS Release 14.2. 


Description 
Configure an interface in OSPF passive traffic engineering mode to enable dynamic discovery of OSPF AS 
boundary routers. 


Default 


OSPF passive traffic-engineering mode is disabled. 


Options 


remote-node-id address—IP address at the far end of the inter-AS link. 


remote-node-router-id address—Router ID at the far end of the inter-AS link. 


NOTE: The remote-node-router-id address option does not apply under the [edit 
routing-instances routing-instance-name] and [edit protocols ospf3 area area-id] hierarchy 
levels. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Passive Traffic Engineering Mode | 403 
MPLS Applications User Guide 
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| transit-delay (OSPF) 


Syntax 


transit-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Set the estimated time required to transmit a link-state update on the interface. When calculating this 
time, make sure to account for transmission and propagation delays. 


You should never have to modify the transit delay time. 


Options 
seconds—Estimated time, in seconds. 
Range: 1 through 65,535 seconds 
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Default: 1 second 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers | 283 
Configuring RSVP and OSPF for LMP Peer Interfaces 
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| type-7 


Syntax 


type-7; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id nssa default-lsa], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
nssa default-lsa], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id nssa default-lsa], 

[edit protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6é-multicast) area area-id nssa default-lsa], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id nssa default-lsa], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 
area area-id nssa default-lsa] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 


Flood Type 7 default link-state advertisements (LSAs) if the no-summaries statement is configured. 


By default, when the no-summaries statement is configured, a Type 3 LSA is injected into not-so-stubby 
areas (NSSAs) for Junos OS Release 5.0 and later. To support backward compatibility with earlier Junos 
OS releases, include the type-7 statement. This statement enables NSSA ABRs to advertise a Type 7 
default LSA into the NSSA if you have also included the no-summaries statement in the configuration. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
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Example: Configuring OSPF Not-So-Stubby Areas | 107 


no-summaries | 755 
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| use-post-convergence-lfa (Protocols OSPF) 


Syntax 


use-post-convergence-lfa <maximum-backup-paths maximum-backup-paths> <maximum-labels maximum-labels> ; 


Hierarchy Level 


[edit logical-systems name protocols ospf backup-spf-options], 

[edit logical-systems name routing-instances name protocols ospf backup-spf-options], 
[edit protocols ospf backup-spf-options], 

[edit routing-instances name protocols ospf backup-spf-options] 


Release Information 
Statement introduced in Junos OS Release 18.2R1 for MX Series, PTX Series, and QFX Series. 


Description 

Calculate post-convergence MPLS fast reroute (FRR) backup next hops for the OSPF protocol using 
segment routing (SR). Junos OS allows you to control the maximum number of equal-cost multipath (ECMP) 
backup paths installed for a given destination. Junos OS also allows you to control the maximum number 
of labels in the installed backup paths. Configure the use-source-packet-routing statement at [edit protocols 
ospf backup-spf-options] hierarchy level to allow the backup paths to be available for inet.0 routing table 
along with inet.3 routing table. 


Options 

maximum-backup-paths—Set the maximum number of equal-cost post-convergence backup paths to be 
installed. 
Default: 1 
Range: 1-8 


maximum-labels—Set the maximum number of labels used to construct a post-convergence backup path. 
If the backup path for a particular prefix requires more labels than the configured maximum labels, 
then the backup path for that particular prefix is not installed. 


NOTE: If the maximum-labels option is not configured, then the maximum number of labels 
used to construct a post-convergence backup path is 3. 


Default: 3 
Range: 2-5 


Required Privilege Level 
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routing 


RELATED DOCUMENTATION 


post-convergence-lfa | 720 


Topology-Independent Loop-Free Alternate with Segment Routing for OSPF | 450 
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| virtual-link 
Syntax 


virtual-link neighbor-id router-id transit-area area-id { 
disable; 
authentication key <key-id identifier>; 
dead-interval seconds; 
hello-interval seconds; 
ipsec-sa name; 
retransmit-interval seconds; 
transit-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id], 
[edit protocols (ospf | ospf3) area area-id], 

[edit routing-instances routing-instance-name protocols ospf area area-id] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.0 for EX Series switches. 


Description 

For backbone areas only, create a virtual link to use in place of an actual physical link. All area border 
routers and other routing devices on the backbone must be contiguous. If this is not possible and there is 
a break in OSPF connectivity, use virtual links to create connectivity to the OSPF backbone. When 
configuring virtual links, you must configure links on the two routing devices that form the end points of 
the link, and both of these routing devices must be area border routers. You cannot configure links through 
stub areas. 


Options 


neighbor-id router-id—IP address of the routing device at the remote end of the virtual link. 


transit-area area-id—Area identifier of the area through which the virtual link transits. Virtual links are not 
allowed to transit the backbone area. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding OSPF Areas | 65 
Example: Configuring OSPF Virtual Links to Connect Noncontiguous Areas | 159 


CHAPTER 20 


Operational Commands 
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| clear bfd adaptation 


Syntax 


clear bfd adaptation 


<all> 
<address session-address> 
<discriminator discr-number> 


Release Information 
Command introduced before Junos OS Release 7.4. 


Description 

Clear adaptation for Bidirectional Forwarding Detection (BFD) sessions. BFD is a simple hello mechanism 
that detects failures in a network. Configured BFD interval timers can change, adapting to network 
situations. Use this command to return BFD interval timers to their configured values. 


The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on 
the routing device. 


Options 


all—Clear adaptation for all BFD sessions. 
address session-address—(Optional) Clear adaptation for all BFD sessions matching the specified address. 


discriminator discr-number—(Optional) Clear adaptation for the local BFD session matching the specified 
discriminator. 


Additional Information 


For more information, see the description of the bfd-liveness-detection configuration statement in the 
Junos Routing Protocols Configuration Guide. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show bfd session | 797 


List of Sample Output 
clear bfd adaptation on page 780 


Output Fields 
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When you enter this command, you are provided feedback on the status of your request. 


| Sample Output 


clear bfd adaptation 


user@host> Clear bfd adaptation 
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| clear bfd session 


List of Syntax 
Syntax on page 781 
Syntax (EX Series Switch and QFX Series) on page 781 


Syntax 


clear bfd session 

<all> 

<address session-address> 

<discriminator discr-number> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switch and QFX Series) 


clear bfd session 

<all> 

<address session-address> 
<discriminator discr-number> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 12.1 for the QFX Series. 


Description 


Drop one or more Bidirectional Forwarding Detection (BFD) sessions. 


Options 


all—Drop all BFD sessions. 
address session-address—(Optional) Drop all BFD sessions matching the specified address. 
discriminator discr-number—(Optional) Drop the local BFD session matching the specified discriminator. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 
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show bfd session | 797 


List of Sample Output 
clear bfd session all on page 782 


Output Fields 
When you enter this command, you are provided feedback on the status of your request. 


| Sample Output 


clear bfd session all 


user@host> Clear bfd session all 


| clear (ospf | ospf3) database 


List of Syntax 
Syntax on page 783 
Syntax (EX Series Switch and QFX Series) on page 783 


Syntax 


clear (ospf | ospf3) database 

<all> 

<advertising-router (router-id | self)> 
<area area-id> 

<asbrsummary> 

<external> 

<instance instance-name> 
<inter-area-prefix> 

<inter-area-router> 

<intra-area-prefix> 

<link-local> 

<logical-system (all | logical-system-name)> 
<Isa-id Isa-id> 

<netsummary> 

<network> 

<nssa> 

<opaque-area> 

<purge> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


<router> 


Syntax (EX Series Switch and QFX Series) 


clear (ospf | ospf3) database 
<all> 

<advertising-router (router-id | self)> 
<area area-id> 
<asbrsummary> 

<external> 

<instance instance-name> 
<inter-area-prefix> 
<inter-area-router> 
<intra-area-prefix> 
<link-local> 

<lsa-id Isa-id> 
<netsummary> 
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<network> 
<nssa> 
<opaque-area> 
<purge> 


<router> 


Release Information 

Command introduced before Junos OS Release 7.4. 

advertising-router router-id, netsummary, network, nssa, opaque-area, and router options added in Junos 
OS Release 8.3. You must use the purge command with these options. 

area area-id option added in Junos OS Release 8.3. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option added in Junos OS Release 9.2. 

advertising-router (router-id | self) option added in Junos OS Release 9.5. 

advertising-router (router-id | self) option introduced in Junos OS Release 9.5 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 

Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 

purge option (and all options that are dependent on the purge option) hidden in Junos OS Release 13.3. 


Description 

With the master Routing Engine, delete entries in the Open Shortest Path First (OSPF) link-state 
advertisement (LSA) database. With the backup Routing Engine, delete the OSPF LSA database and sync 
the new database with the master Routing Engine. 


4 

y 
; CAUTION: You can also use the purge command with any of the options to discard 
A rather than delete the specified LSA entries. This command is useful only for testing. 


Use it with care, because it causes significant network disruption. 


Options 

all—Delete all LSAs other than the system’s own LSAs, which are regenerated. To resynchronize the 
database, the system destroys all adjacent neighbors that are in the state EXSTART or higher. The 
neighbors are then reacquired and the databases are synchronized. 


advertising-router (router-id | self)—(Optional) Discard entries for the LSA entries advertised by the specified 
routing device or by this routing device. 


area area-id—(Optional) Discard entries for the LSAs in the specified area. 
asbrsummary—(Optional) Discard summary AS boundary router LSA entries. 


external—(Optional) Discard external LSAs. 
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instance instance-name—(Optional) Delete or discard entries for the specified routing instance only. 
inter-area-prefix—(OSPFv3 only) (Optional) Discard interarea prefix LSAs. 
inter-area-router—(OSPFv3 only) (Optional) Discard interarea router LSAs. 
intra-area-prefix—(OSPFv3 only) (Optional) Discard intra-area prefix LSAs. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


link-local—(Optional) Delete link-local LSAs. 

Isa-id Isa-id—(Optional) Discard the LSA entries with the specified LSA identifier. 
netsummary—(Optional) Discard summary network LSAs. 

network—(Optional) Discard network LSAs. 

nssa—(Optional) Discard not-so-stubby area (NSSA) LSAs. 
Opaque-area—(Optional) Discard opaque area-scope LSAs. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(OSPFv3 only) (Optional) Delete the entries for the 
specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


router—(Optional) Discard router LSAs. 


purge—(Optional) Discard all entries in the link-state advertisement database. All link-state advertisements 
are set to MAXAGE and are flooded. The database is repopulated when the originators of the link-state 
advertisements receive the MAXAGE link-state advertisements and reissue them. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show ospf database | 819 
show ospf3 database | 828 


List of Sample Output 
clear ospf database all on page 786 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 
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Sample Output 


clear ospf database all 


user@host> Clear ospf database all 
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| clear (ospf | ospf3) database-protection 


Syntax 


clear (ospf | ospf3) database-protection 
<instance instance-name> 


Release Information 
Command introduced in Junos OS Release 10.2. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 


Description 
Clear the Open Shortest Path First (OSPF) link-state database from its isolated state. Reset the ignore 
count, ignore timer, and reset timer, and resume normal operations. 


Options 
instance instance-name—(Optional) Clear the OSPF link-state database for the specified routing instance 
only. 


Required Privilege Level 
clear 


Output Fields 


This command produces no output. 


| Sample Output 


clear ospf database-protection 


user@host> clear ospf database-protection 
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| clear (ospf | ospf3) io-statistics 


List of Syntax 
Syntax on page 788 
Syntax (EX Series Switch and QFX Series) on page 788 


Syntax 


clear (ospf | osfp3) io-statistics 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switch and QFX Series) 


clear (ospf | osfp3) io-statistics 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Clear Open Shortest Path First (OSPF) input and output statistics. 


Options 
none—Clear OSPF input and output statistics. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


List of Sample Output 
clear ospf io-statistics on page 789 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 
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Sample Output 


clear ospf io-statistics 


user@host> Clear ospf io-statistics 


| clear (ospf | ospf3) neighbor 


List of Syntax 
Syntax on page 790 
Syntax (EX Series Switch and QFX Series) on page 790 


Syntax 


clear (ospf | ospf3) neighbor 

<all> 

<area area-id> 

<instance instance-name> 

<interface interface-name> 

<logical-system (all | logical-system-name)> 

<neighbor> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switch and QFX Series) 


clear (ospf | ospf3) neighbor 
<all> 

<area area-id> 

<instance instance-name> 
<interface interface-name> 
<neighbor> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Tear down Open Shortest Path First (OSPF) neighbor connections. 


Options 


all—Tear down OSPF connections with all neighbors for all routing instances. 
area area-id—(Optional) Tear down neighbor connections for the specified area only. 


instance instance-name—(Optional) Tear down neighbor connections for the specified routing instance 
only. 
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interface interface-name—(Optional) Tear down neighbor connections for the specified interface only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


neighbor—(Optional) Clear the state of the specified neighbor only. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(Optional) (OSPFv3 only) Clear the state of the 
specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 
show (ospf | ospf3) neighbor | 848 


List of Sample Output 
clear ospf neighbor all on page 791 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


Sample Output 


clear ospf neighbor all 


user@host> clear ospf neighbor all 
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| clear (ospf | ospf3) overload 


List of Syntax 
Syntax on page 792 
Syntax (EX Series Switches) on page 792 


Syntax 


clear (ospf | ospf3) overload 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


clear (ospf | ospf3) overload 
<instance instance-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Clear the Open Shortest Path First (OSPF) overload bit and rebuild link-state advertisements (LSAs). 


Options 


none—Clear the overload bit and rebuild LSAs for all routing instances. 


instance instance-name—(Optional) Clear the overload bit and rebuild LSAs for the specified routing instance 
only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


List of Sample Output 
clear ospf overload on page 793 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


793 


Sample Output 


clear ospf overload 


user@host> clear ospf overload 
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| clear (ospf | ospf3) statistics 


List of Syntax 
Syntax on page 794 
Syntax (EX Series Switch and QFX Series) on page 794 


Syntax 


clear (ospf | osfp3) statistics 

<instance instance-name> 

<logical-system (all | logical-system-name)> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switch and QFX Series) 


clear (ospf | osfp3) statistics 
<instance instance-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Clear Open Shortest Path First (OSPF) statistics. 


Options 


none—Clear OSPF statistics. 
instance instance-name—(Optional) Clear statistics for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(Optional) (OSPFv3 only) Clear statistics for the 
specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show (ospf | ospf3) statistics | 868 


List of Sample Output 
clear ospf statistics on page 795 


Output Fields 


See show (ospf | ospf3) statistics for an explanation of output fields. 


Sample Output 


clear ospf statistics 


The following sample output displays OSPF statistics before and after the clear ospf statistics command 


is entered: 


user@host> show ospf statistics 





Packet types 
Sent 
Hello 3254 
DbD 41 
LSReq 8 
LSUpdate 22 
LSAck 65 
DBDs retransmitted 
LSAs flooded 
LSAs flooded high-prio 
LSAs retransmitted 
LSAs transmitted to nbr: 
LSAs requested 
LSAs acknowledged 





Flood queue depth 


Total rexmit entries 


db summaries 


lsreq entries 


Receive errors: 


626 subnet mismatches 


Total 


Received 
2268 

46 

7 

154 

98 


Sa 2 oS © 


Last 5 seconds 


Sent 

3 

0 

0 

0 

0 
a, Last 
12, dhawsic 
UO, Last 
0, last 
oa last 
oS, Last 
IQ, lasic 





Gn Xn Gn Gl Gt GaGa) 


Received 


seconds 
seconds 
seconds 
seconds 
seconds 
seconds 


seconds 


ale 


0 
0 
0 
0 


(on te5 er jer ser ea) =) 
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user@host> Clear ospf statistics 


user@host> show ospf statistics 


Packet types 





DBDs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 





LSReq 
LSUpdate 
LSAck 


sent 


Hello 3 


DbD 


Se eS 2 & 


retransmitted 
flooded 
flooded high-prio 


retransmitted 


transmitted to nbr: 


requested 


acknowledged 


Flood queue depth 


Total rexmit entries 


db summaries 


lsreq entries 


Receive errors: 


None 


Total 
Received 
1 


0 
0 
0 
0 


Sa a oo © 


Last 5 seconds 


Sent 


3 
0 
0 
0 
0 


Ralsit 
last 
last 
last 
last 


last 





last 


(Gn Gn) Gn Gl GGG) 


Received 


seconds 
seconds 
seconds 
seconds 
seconds 
seconds 


seconds 


i 


0 
0 
0 
0 


Soro ea) So) (So) eo) = 
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| show bfd session 


List of Syntax 
Syntax on page 797 
Syntax (EX Series Switch and QFX Series) on page 797 


Syntax 


show bfd session 

<brief | detail | extensive | summary> 

<address address> 

<client rsvp-oam (brief | detail | extensive | summary) | vpls-oam (brief | detail | extensive | instance instance-name 
| summary)> 

<discriminator discriminator> 

<logical-system (all | logical-system-name)> 

<prefix address> 

<subscriber (address destination-address | discriminator discriminator | extensive)> 


Syntax (EX Series Switch and QFX Series) 


show bfd session 

<brief | detail | extensive | summary> 

<address address> 

<client rsvp-oam (brief | detail | extensive | summary) | vpls-oam (brief | detail | extensive | instance instance-name 
| summary)> 

<discriminator discriminator> 

<prefix address> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Options discriminator and address introduced in Junos OS Release 8.2. 
Option prefix introduced in Junos OS Release 9.0. 

Command introduced in Junos OS Release 12.1 for the QFX Series. 
Option client introduced in Junos OS Release 12.3R3. 

Option subscriber introduced in Junos OS Release 15.1 for the MX Series. 


Description 


Display information about active Bidirectional Forwarding Detection (BFD) sessions. 


Options 


none—(Same as brief) Display information about active BFD sessions. 


brief | detail | extensive | summary—(Optional) Display the specified level of output. 
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address address—(Optional) Display information about the BFD session for the specified neighbor address. 


client rsvp-oam 
(brief | detail | extensive | summary) 
| vpls-oam 
(brief | detail | extensive | instance instance-name | summary)—(Optional) Display information about 
RSVP-OAM or VPLS-OAM BFD sessions in the specified level of output. For VPLS-OAM, display the 
specified level of output or display information about all of the BFD sessions for the specified VPLS 
routing instance. 


discriminator discriminator—(Optional) Display information about the BFD session using the specified local 
discriminator. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


<subscriber (address destination-address | discriminator discriminator | extensive)>—(Optional) Display 
information about all BFD sessions for subscribers, or for a single BFD subscriber session with a 
particular destination address, or with a particular denominator. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear bfd session | 781 

Understanding BFD for Static Routes for Faster Network Failure Detection 
Understanding BFD for OSPF | 292 

Understanding BFD for BGP 

Understanding Bidirectional Forwarding Detection Authentication for PIM 
Configuring BFD for PIM 

Understanding BFD for IS-IS 





List of Sample Output 

show bfd session on page 804 
show bfd session brief on page 804 
show bfd session detail on page 804 


Output Fields 


Table 8 on page 799 describes the output fields for the show bfd session command. Output fields are listed 
in the approximate order in which they appear. 


Table 8: show bfd session Output Fields 


Field Name 


Address 


State 


Interface 


Detect Time 


Transmit Interval 


Multiplier 


Session up time 


Client 


TX interval 


RX interval 


Authenticate 


keychain 


Field Description 


Address on which the BFD session is active. 


State of the BFD session: Up, Down, Init (initializing), or Failing. 


Interface on which the BFD session is active. 


Negotiated time interval, in seconds, used to detect BFD control packets. 


Time interval, in seconds, used by the transmitting system to send BFD 


control packets. 


Negotiated multiplier by which the time interval is multiplied to determine 
the detection time for the transmitting system. 


How long a BFD session has been established. 


Protocol or process for which the BFD session is active: ISIS, OSPF, DHCP, 
Static, or VGD. 


Time interval, in seconds, used by the host system to transmit BFD control 
packets. 


Time interval, in seconds, used by the host system to receive BFD 
control packets. 


Indicates that BFD authentication is configured. 


Name of the security authentication keychain being used by a specific 
client. 


BFD authentication information for a client is provided in a single line and 
includes the keychain, algo, and mode parameters. Multiple clients can 
be configured ona BFD session. 
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Level of Output 


brief detail extensive 
none 


brief detail extensive 
none 


brief detail extensive 
none 


brief detail extensive 
none 


brief detail extensive 
none 


detail extensive 


detail extensive 


detail extensive 


brief detail extensive 


none 


brief detail extensive 
none 


detail extensive 


extensive 


Table 8: show bfd session Output Fields (continued) 


Field Name 


algo 


mode 


Local diagnostic 


Field Description 


BFD authentication algorithm being used for a specific client: keyed-md5, 
keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or 
simple-password. 


BFD authentication information for a client is provided in a single line and 
includes the keychain, algo, and mode parameters. Multiple clients can 
be configured on a BFD session. 


Level of BFD authentication enforcement being used by a specific client: 
strict or loose. Strict enforcement indicates that authentication is 
configured at both ends of the session (the default). Loose enforcement 
indicates that one end of the session might not be authenticated. 


BFD authentication information for a client is provided in a single line and 
includes the keychain, algo, and mode parameters. Multiple clients can 
be configured on a BFD session. 


Local diagnostic information about failing BFD sessions. 
Following are the expected values for Local Diagnostic output field: 


e None—No diagnostic 
e CtlExpire—Control detection time expired 


EchoExpire—Echo detection time expired 


e NbrSignal—Neighbor signalled session down 
e FwdPlaneReset—Forwarding plane reset 


PathDown—Path down 


e ConcatPathDown—Concatenated path down 


AdminDown—Administratively down 
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Level of Output 


extensive 


extensive 


detail extensive 


Table 8: show bfd session Output Fields (continued) 


Field Name 


Remote 
diagnostic 


Remote state 


Version 


Replicated 


Min async 
interval 


Min slow interval 


Adaptive async 


TX interval 


RX interval 


Local min TX 
interval 


Local min RX 
interval 


Remote min TX 
interval 


Field Description 


Remote diagnostic information about failing BFD sessions. 
Following are the expected values for Remote Diagnostic output field: 


None—No diagnostic 


e CtlExpire—Control detection time expired 


EchoExpire—Echo detection time expired 


e NbrSignal—Neighbor signalled session down 


FwdPlaneReset—Forwarding plane reset 


PathDown—Path down 


e ConcatPathDown—Concatenated path down 


AdminDown—Administratively down 


Reports whether the remote system's BFD packets have been received 
and whether the remote system is receiving transmitted control packets. 


BFD version: 0 or 1. 
The replicated flag appears when nonstop routing or graceful Routing 
Engine switchover is configured and the BFD session has been replicated 


to the backup Routing Engine. 


Minimum amount of time, in seconds, between asynchronous control 
packet transmissions across the BFD session. 


Minimum amount of time, in seconds, between synchronous control 
packet transmissions across the BFD session. 


Transmission interval being used because of adaptation. 


Minimum required receive interval. 


Minimum amount of time, in seconds, between control packet 
transmissions on the local system. 


Minimum amount of time, in seconds, between control packet detections 
on the local system. 


Minimum amount of time, in seconds, between control packet 
transmissions on the remote system. 
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Level of Output 


detail extensive 


detail extensive 


extensive 


detail extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


Table 8: show bfd session Output Fields (continued) 


Field Name 


Remote min TX 
interval 


Threshold 
transmission 
interval 


Threshold for 
detection time 


Local 
discriminator 


Remote 
discriminator 


Echo mode 
Prefix 
Egress, 


Destination 


Remote is 
control-plane 
independent 


Field Description 


Minimum amount of time, in seconds, between control packet detections 
on the remote system. 


Threshold for notification if the transmission interval increases. 


Threshold for notification if the detection time increases. 


Authentication code used by the local system to identify that BFD session. 


Authentication code used by the remote system to identify that 
BFD session. 


Information about the state of echo transmissions on the BFD session. 


LDP FEC address associated with the BFD session. 


Displays the LDP FEC destination address. This field is displayed only on 
a router at the egress of an LDP FEC, where the BFD session has an LDP 
Operation, Administration, and Maintenance (OAM) client. 


The BFD session on the remote peer is running on its Packet Forwarding 
Engine. In this case, when the remote node undergoes a graceful restart, 
the local peer can help the remote peer with the graceful restart. 


The following BFD sessions are not distributed to the Packet Forwarding 
Engine: tunnel-encapsulated sessions, and sessions over integrated routing 
and bridging (IRB) interfaces. 
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Level of Output 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


All levels 


All levels 


extensive 
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Table 8: show bfd session Output Fields (continued) 


Field Name Field Description Level of Output 


Authentication Summary status of BFD authentication: extensive 


e status—enabled/active indicates authentication is configured and active. 
enabled/inactive indicates authentication is configured but not active. 
This only occurs when the remote end of the session does not support 
authentication and loose checking is configured. 


e keychain—Name of the security authentication keychain associated 
with the specified BFD session. 


e algo—BFD authentication algorithm being used: keyed-md5, 
keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or 
simple-password. 

e mode—Level of BFD authentication enforcement: strict or loose. Strict 
enforcement indicates authentication is configured at both ends of the 
session (the default). Loose enforcement indicates that one end of the 
session might not be authenticated. 


This information is only shown if BFD authentication is configured. 


Session ID The BFD session ID number that represents the protection using MPLS | detail extensive 
fast reroute (FRR) and loop-free alternate (LFA). 


sessions Total number of active BFD sessions. All levels 
clients Total number of clients that are hosting active BFD sessions. All levels 
Cumulative Total number of BFD control packets transmitted per second on all All levels 
transmit rate active sessions. 

Cumulative Total number of BFD control packets received per second on all All levels 
receive rate active sessions. 

Multi-hop, Minimum time to live (TTL) accepted if the session is configured for extensive 
min-recv-TTL multihop. 

route table Route table used if the session is configured for multihop. extensive 
local address Local address of the source used if the session is configured for multihop. | extensive 


The source IP address for outgoing BFD packets from the egress side of 
an MPLS BFD session is based on the outgoing interface IP address. 


| Sample Output 


show bfd session 


user@host> show bfd session 








Transmit 
Address State Interfac Detect Tim Interval 
10.9.1.33 Up Sonya Or0 0.600 0.200 
10.9,1.29) Up ge-4/0/0.0 0.600 0.200 
2 sessions, 2 clients 
Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps 


show bfd session brief 
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Multiplier 
3 
3 


The output for the show bfd session brief command is identical to that for the show bfd session command. 


show bfd session detail 


user@host> show bfd session detail 





Transmit 
Address State Interfac Detect Tim Interval 
10.9 1.33 Up Soni /su/0R0) 0.600 0.200 


Clieinc OS, IDK amceryval ©, 200, 
Session up time 3d 00:34:02 


RX interval 0.200, multiplier 3 


Local diagnostic None, remote diagnostic None 





Remote state Up, version 1 
Replicated 
19,9, 1.29) Up ge-4/0/0.0 0.600 0.200 


Cligme USUS we, IX sincemyall 0,200, 
Session up time 3d 00:29:04, 


RX interval 0.200, multiplier 3 


previous down time 00:00:01 
Local diagnostic NbrSignal, remote diagnostic AdminDown 


Remote stat version 1 





Up, 


2 sessions, 2 clients 


cumulative receive rat 





Cumulative transmit rate 10.0 pps, OR OM OOS 


Multiplier 
3 
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| show (ospf | ospf3) backup coverage 
Syntax 


show (ospf | ospf3) backup coverage 
<instance instance-name> 

< logical-system (all | logical-system-name)> 
<realm (ipv4-unicast | ipv46-unicast> 
<topology topology-name> 


Syntax (QFX Series) 


show (ospf | ospf3) backup coverage 
<instance instance-name> 


<topology topology-name> 


Release Information 

Command introduced in Junos OS Release 10.0. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display information about the level of backup coverage available for all the nodes and prefixes in the 
network. 


Options 
none—Display information about the level backup coverage for all OSPF routing instances in all logical 
systems. 


logical-system (all | logical-system-name)—(Optional) Display information about the level of backup coverage 
for all logical systems or for a specific logical system. 


instance instance-name—(Optional) Display information about the level of backup coverage for a specific 
OSPF routing instance. 


realm (ipv4-unicast | ipv6-unicast)—(Optional) (OSPFv3 only) Display information about the level of backup 
coverage for the specific OSPFv3 realm, or address family. 


topology (default | topology-name)—(Optional) (OSPF v2 only) Display information about the level of backup 
coverage for the specific OSPF topology. 


Required Privilege Level 
view 
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RELATED DOCUMENTATION 


show (ospf | ospf3) backup Isp | 808 


List of Sample Output 
show ospf backup coverage on page 806 
show ospf3 backup coverage on page 807 


Output Fields 


Table 9 on page 806 lists the output fields for the show (ospf | ospf3) backup coverage command. Output 
fields are listed in the approximate order in which they appear. 


Table 9: show (ospf | ospf3) backup coverage Output Fields 


Field Name Field Description 


rmorn, June 2020: Uplift | Information about backup coverage for each OSPF node. 
project, general cleanup 


Area Area number. Area 0.0.0.0 is the backbone. 

Covered Nodes Number of nodes for which backup coverage is available. 

Total Nodes Total number of OSPF nodes. 

Route Coverage Information about backup coverage for each type of OSPF 
route. 

Path Type Type of OSPF path: Intra, Inter, Ext1, Ext2, and All. 

Covered Routes For each path type, the number of routes for which backup 


coverage is available. 
Total Routes For each path type, the total number of configured routes. 


Percent Covered For all nodes and for each path type, the percentage for which 
backup coverage is available. 


| Sample Output 


show ospf backup coverage 


user@host> show ospf backup coverage 
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Topology default coverage: 


Node Coverage: 





Area Covered Total Percent 
Nodes Nodes Covered 
OR ORR 0 4 5 80.00% 


Route Coverage: 








Path Type Covered Total Percent 

ROUEeS me ROuUuCS EC ovycnced 
Intra 8 14 57.14% 
Inter 0 OF L0OR 00 
Extl 0 ORO ORO 
Ext2 A 1 100.00% 
All g) 15 60.00% 


show ospf3 backup coverage 


user @host > show ospf3 backup coverage 


show ospf3 backup coverage 


Node Coverage: 





Area Covered Total Percent 
Nodes Nodes Covered 
OR OR ORO 4 5 80.00% 


Route Coverage: 








Path Type Covered Total Percent 

ROMEC Sm eUiEC SMC Ovo ECE 
Intra 4 6 66.67% 
Inter 0 CO FOOR OO -s 
Extl 0 0 100.00% 
Bxt 2 al 1 100.00% 
All 5) 7 71.43% 
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| show (ospf | ospf3) backup Isp 
Syntax 


show (ospf | ospf3) backup Isp 
<logical-system (all | logical-system-name> 
<realm (ipv4-unicast | ipv6-unicast)> 


Release Information 
Command introduced in Junos OS Release 10.0. 


Description 


Display information about MPLS label-switched-paths (LSPs) designated as backup routes for OSPF routes. 


NOTE: MPLS LSPs can be used as backup routes only for routes in the default OSPFv2 topology 
and not for any configured topology. Additionally, MPLS LSPs cannot be used as backup routes 
for nondefault instances either for OSPFv2 or OSPF v3. 


Options 


none—Display information all MPLS LSPs designated as backup routes. 


logical-system (all | logical-system-name)—(Optional) Display information about MPLS LSPs designated as 
backup routes for all logical systems or a specific logical system. 


realm (ipv4-unicast | ipv6-unicast)—(Optional) (OSPFv3 only) Display information about MPLS LSPs 
designated as backup routes for a specific realm, or address family. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


| show (ospf | ospf3) backup coverage | 805 


List of Sample Output 
show ospf backup Isp on page 809 
show ospf3 backup Isp on page 810 


Output Fields 


Table 10 on page 809 lists the output fields for the show (ospf | ospf3) backup Isp command. Output fields 


are listed in the approximate order in which they appear. 


Table 10: show (ospf | ospf3) backup Isp Output Fields 


Field Name Field Description 

MPLS LSP name Name of each MPLS LSP designated as a backup path. 
Egress IP address of the egress router for the LSP. 

Status State of the LSP: 


e Up—The router can detect RSVP hello messages from the 
neighbor. 


e Down—The router has received one of the following 
indications: 


e Communication failure from the neighbor. 
e Communication from IGP that the neighbor is unavailable. 


e Change in the sequence numbers in the RSVP hello 
messages sent by the neighbor. 


e Deleted—The LSP is no longer available as a backup path. 


Last change Time elapsed since the neighbor state changed either from up 
or down or from down to up. The format is hh:mm:ss. 


TE-metric Configured traffic engineering metric. 


Metric Configured metric. 


| Sample Output 
show ospf backup Isp 


user@host> show ospf backup Isp 


tobanff 
Horess 7) L0RZ oo. (1.2397 Stacus:, Up, hast change: 00 00k 23 








TE-metric: 0, Metric: 0 
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| Sample Output 
show ospf3 backup Isp 


user@host> show ospf3 backup Isp 


tobanff 
Beeesse 10.255, 71,239, SeMewss Uo, ikeisie Clasinges OWeWWs4s 








Wisweciaikes O, wees 0) 
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| show (ospf | ospf3) backup neighbor 
Syntax 


show (ospf | ospf3) backup neighbor 

<area area-id> 

<instance (default | instance-name)> 

<logical-system (default | ipv4-multicast | logical-system-name)> 
<topology (default | ipv4-multicast | topology-name)> 


Syntax (QFX Series) 


show (ospf | ospf3) backup neighbor 

<area area-id> 

<instance instance-name> 

<topology (default | ipv4-multicast | topology-name)> 


Release Information 

Command introduced in Junos OS Release 10.0. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Display the neighbors through which direct next hops for the backup paths are available. 


Options 
none—Display all neighbors that have direct next hops for backup paths. 


area area-id—(Optional) Display the area information. 


instance (default | instance-name)—(Optional) Display information about the default routing instance or a 
particular routing instance. 


logical-system (default | ipv4-multicast | logical-system-name)—(Optional) Display information about the 
default logical system, IPv4 multicast logical system, or a particular logical system. 


topology (default | ipv4-multicast | topology-name)—(OSPFv2 only) (Optional) Display information about 
the default topology, IPv4 multicast topology, or a particular topology. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show (ospf | ospf3) backup spf | 813 


List of Sample Output 
show ospf backup neighbor on page 812 


Output Fields 
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Table 11 on page 812 lists the output fields for the show (ospf |ospf3) backup neighbor command. Output 


fields are listed in the approximate order in which they appear. 
Table 11: show (ospf |ospf3) backup neighbor Output Fields 


Field Name Field Description 


Neighbor to Self | Metric from the backup neighbor to the OSPF node. 


Metric 


Self to Neighbor | Metric from the OSPF node to the backup neighbor. 


Metric 


Direct next-hop Interface and address of the direct next hop. 


| Sample Output 


show ospf backup neighbor 


user@host> show ospf backup neighbor 


Topology default backup neighbors: 
Area 0.0.0.5 backup neighbors: 


10 60.0.5 
Neighbor to Self Metric: 5 
Self to Neighbor Metric: 5 
Direct next-hop: ge-4/0/0.111 via 10.0.175.5 


10.0.0.6 
Neighbor to Self Metric: 5 
Self to Neighbor Metric: 5 
Direct next-hop: ge-4/1/0.110 via 10.0.176.6 





Level of Output 


All levels 


All levels 


All levels 
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| show (ospf | ospf3) backup spf 
Syntax 


show (ospf | ospf3) backup spf 

<brief | detail> 

<area area-id> 

<instance instance-name> 

<logical-system (all | logical-system-name> 
<no-coverage> 

<node-id> 

<realm (ipv4-unicast | ipv6-unicast)> 

<topology (default | ipv4-multicast | topology-name)> 


Syntax (QFX Series) 


show (ospf | ospf3) backup spf 

<brief | detail> 

<area area-id> 

<instance instance-name> 

<no-coverage> 

<node-id> 

<topology (default | ipv4-multicast | topology-name)> 


Release Information 
Command introduced in Junos OS Release 10.0. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 


Description 


Display information about OSPF shortest-path-first calculations for backup paths. 


Options 
none—Display information about OSPF shortest-path-first (SPF) calculations for all backup paths for all 
destination nodes. 


brief | detail—(Optional) Display the specified level of output. 
area area-id—(Optional) Display the area information. 
instance instance-name—(Optional) Display information about the routing instance. 


logical-system (all | logical-system-name)—(Optional) Display information about all logical systems or a 
specific logical system. 


no-coverage—(Optional) Display information if there is no backup coverage. 
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node-id—(Optional) Display information about the node specified. 
realm (ipv4-unicast | ipv6-unicast)—(Optional) Display information about the ipv4 or ipvé realm. 


topology (default | ipv4-multicast | topology-name)—(Optional) (OSPFv2 only) Display information about 
the default topology, IPv4 multicast topology, or a specifc topology. 


Required Privilege Level 
view 


List of Sample Output 
show ospf backup spf on page 815 


Output Fields 


Table 12 on page 814 lists the output fields for the show (ospf |Jospf3) backup spf command. Output fields 
are listed in the approximate order in which they appear. 


Table 12: show (ospf |ospf3) backup spf Output Fields 


Field Name Field Description Level of Output 

Area area-id Area for which the results are displayed. Area 0.0.0.0 is the backbone All levels 

results area. 

address Address of the node for which the results are displayed. All levels 

Self to Metric from the node to the destination. All levels 

Destination 

Metric 

Parent Node Address of the parent node. All levels 

Primary next-hop | Address of the next hop. All levels 

Backup Neighbor | Address of the backup neighbor or LSP endpoint and the following All levels 
information: 


e Neighbor to Destination Metric 
e Neighbor to Self Metric 
e Self to Neighbor Metric 


e Status (Eligible, Not Eligible, Not Evaluated) and the reason for the 
status. 


NOTE: If the backup neighbor is an LSP endpoint, it is indicated as such 
after the neighbor address. 
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| Sample Output 


show ospf backup spf 


user@host> show ospf backup spf 


Topology default results: 
Area 0.0.0.0 results: 


prol6—-d-1o0.xxx.yyyy.net 

Self to Destination Metric: 1 

Parent Node: prol6—-b-100.xxx.yyyy.net 

Primary next—-hop: at-1/0/1.0 

Backup Neighbor: prol6-c-lo0.xxx.yyyy.net (LSP endpoint) 
Neighbor to Destination Metric: 4, Neighbor to Self Metric: 3 
Self to Neighbor Metric: 3 
Not eligible, Reason: Path loops 
Backup Neighbor: prol6-d-1lo0.xxx.yyyy.net 
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 1 
Self to Neighbor Metric: 1 
Not eligible, Reason: Primary next-hop link fate sharing 
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| show ospf context-identifier 


List of Syntax 
Syntax on page 816 
Syntax (EX Series Switches and QFX Series) on page 816 


Syntax 


show ospf context-identifier 
<brief | detail> 

<area area-id> 

<context-id> 

<instance instance-name> 


<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches and QFX Series) 


show ospf context-identifier 
<brief | detail> 

<area area-id> 

<context-id> 

<instance instance-name> 


Release Information 

Command introduced in Junos OS Release 10.4. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display the context identifier information processed and advertised by Open Shortest Path First (OSPF) 
for egress protection. 


Options 


none—Display information about all context identifiers. 

brief | detail—(Optional) Display the specified level of output. 

area area-id—(Optional) Display information about the context identifier for the specified area. 
context-id—(Optional) Display information about the specified context identifier. 


instance instance-name—(Optional) Display information about the context identifier for the specified 
routing instance. 
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logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 


particular logical system. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


egress-protection (Layer 2 circuit) in the Junos OS VPNs Library for Routing Devices 


egress-protection (MPLS) in the Junos OS VPNs Library for Routing Devices 


List of Sample Output 
show ospf context-identifier on page 818 
show ospf context-identifier detail on page 818 


Output Fields 


Table 13 on page 817 lists the output fields for the show ospf context-identifier command. Output fields 
are listed in the approximate order in which they appear. 


Table 13: show ospf context-identifier Output Fields 


Field Name 


Context 


Status 


Metric 


Area 


Other 
Advertisements 


Field Description 


IPv4 address that defines a protection pair. The context is manually 
configured on both primary and protector provider edge (PE) devices. 


State of the path: active or inactive. 


Advertised OSPF metric. 


OSPF area number. 


Other advertisements received by the OSPF node: 


e Advertising router- Address of the device that sent the advertisement. 
e Type-Type of OSPF path: inter-area and stub. 
e Metric-Advertised OSPF metric. 


e None-No additional advertisements were received by the OSPF node. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


detail 
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| Sample Output 
show ospf context-identifier 


user@host> show ospf context-identifier 


Comcexie—ice 2.2 4,3 
Status: active, Metric: 65534, PE role: protector, Area: 0.0.0.0 





show ospf context-identifier detail 


user@host> show ospf context-identifier detail 


Comicexc—iacls 8 24.13, 1 





Status: inactive, Metric: 0, PE role: protector, Area: 0.0.0.13 
Other Advertisements: 





Advertising router: 8.8.8.103 
Type: stub link 
Metric: 65534 


| show ospf database 


List of Syntax 
Syntax on page 819 
Syntax (EX Series Switches and QFX Series) on page 819 


Syntax 


show ospf database 

<brief | detail | extensive | summary> 
<advertising-router (address | self)> 
<area area-id> 

<asbrsummary> 

<external> 

<instance instance-name> 
<link-local> 

<logical-system (all | logical-system-name)> 
<lsa-id Isa-id> 

<netsummary> 

<network> 

<nssa> 

<opaque-area> 


<router> 


Syntax (EX Series Switches and QFX Series) 


show ospf database 

<brief | detail | extensive | summary> 
<advertising-router (address | self)> 
<area area-id> 

<asbrsummary> 

<external> 

<instance instance-name> 
<link-local> 

<Isa-id Isa-id> 

<netsummary> 

<network> 

<nssa> 

<opaque-area> 


<router> 


Release Information 
Command introduced before Junos OS Release 7.4. 


Command introduced in Junos OS Release 9.0 for EX Series switches. 
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advertising-router self (address | self) option introduced in Junos OS Release 9.5. 

advertising-router self (address | self) option introduced in Junos OS Release 9.5 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 

Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display the entries in the OSPF version 2 (OSPFv2) link-state database, which contains data about link-state 
advertisement (LSA) packets. 


Options 


none—Display standard information about entries in the OSPF v2 link-state database for all routing instances. 
brief | detail | extensive | summary—(Optional) Display the specified level of output. 


advertising-router (address | self)—(Optional) Display the LSAs advertised either by a particular routing 
device or by this routing device. 


area area-id—(Optional) Display the LSAs in a particular area. 
asbrsummary—(Optional) Display summary AS boundary router LSA entries. 
external—(Optional) Display external LSAs. 


instance instance-name—(Optional) Display all OSPF database information under the named routing 
instance. 


link-local—(Optional) Display information about link-local LSAs. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isa-id Isa-id—(Optional) Display the LSA with the specified LSA identifier. 
netsummary—(Optional) Display summary network LSAs. 
network—(Optional) Display information about network LSAs. 
nssa—(Optional) Display information about not-so-stubby area (NSSA) LSAs. 
Opaque-area—(Optional) Display opaque area-scope LSAs. 
router—(Optional) Display information about router LSAs. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 
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clear (ospf | ospf3) database | 783 


List of Sample Output 

show ospf database on page 823 

show ospf database on page 824 

show ospf database brief on page 824 
show ospf database detail on page 825 
show ospf database summary on page 826 


Output Fields 


Table 14 on page 821 describes the output fields for the show ospf database command. Output fields are 
listed in the approximate order in which they appear. 


Table 14: show ospf database Output Fields 


Field Name Field Description Level of Output 
area Area number. Area 0.0.0.0 is the backbone area. All levels 
Type Type of link advertisement: ASBRSum, Extern, Network, NSSA, OpagArea, | All levels 


Router, or Summary. 


ID LSA identifier included in the advertisement. An asterisk preceding the All levels 
identifier marks database entries that originated from the local routing 


device. 
Adv Rtr Address of the routing device that sent the advertisement. All levels 
Seq Link sequence number of the advertisement. All levels 
Age Time elapsed since the LSA was originated, in seconds. All levels 
Opt Optional OSPF capabilities associated with the LSA. All levels 
Cksum Checksum value of the LSA. All levels 


Len Length of the advertisement, in bytes. All levels 
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Table 14: show ospf database Output Fields (continued) 


Field Name 


Router 


Network 


Summary 


Gen timer 


Aging timer 


Installed hh:mm:ss ago 


expires in hh:mm:ss 


sent hh:mm:ss ago 


Last changed hh:mm:ss 
ago 


Change count 


Ours 


Field Description Level of Output 


Router link-state advertisement information: detail extensive 


e bits—Flags describing the routing device that generated the LSP. 
e link count—Number of links in the advertisement. 
e id—ID of a routing device or subnet on the link. 


e data—For stub networks, the subnet mask. Otherwise, the IP address 
of the routing device that generated the LSP. 


e type—Type of link. It can be PointToPoint, Transit, Stub, or Virtual. 


e TOS count—Number of type-of-service (ToS) entries in the 
advertisement. 


e TOS O metric—Metric for ToS O. 
e TOS—Type-of-service (ToS) value. 


e metric—Metric for the ToS. 
Network link-state advertisement information: detail extensive 


e mask—Network mask. 


e attached router—ID of the attached neighbor. 
Summary link-state advertisement information: detail extensive 


e mask—Network mask. 
e TOS—Type-of-service (ToS) value. 


e metric—Metric for the ToS. 


How long until the LSA is regenerated. extensive 
How long until the LSA expires. extensive 
How long ago the route was installed. extensive 
How long until the route expires. extensive 
How long ago the LSA was sent. extensive 
How long ago the route was changed. extensive 
Number of times the route has changed. extensive 
Indicates that this is a local advertisement. extensive 


Table 14: show ospf database Output Fields (continued) 


Field Name 


Router LSAs 


Network LSAs 


Summary LSAs 


NSSA LSAs 


Field Description 


Number of router link-state advertisements in the link-state database. 


Number of network link-state advertisements in the link-state database. 


Number of summary link-state advertisements in the link-state database. 


Number of not-so-stubby area link-state advertisements in the link-state 


database. 


| Sample Output 


show ospf database 


user@host> show ospf database 


OSPF link state database, 


Type 
Router Iti) 
Router *10 
Summary *23 
Summary *24 
NSSA Hi S\5) 


OSPF link state database, 


Type 
Router ALO), 
RewiES ILO), 
Network *23. 
Summary *12. 
Summary *24. 
NSSA OS) 5 


OSPF link state database, 


Type 
Router 10 
Router *10 


Network *24 


Summary *12 


ID 

52596 10.103 
sAOSs WL Bae 
gio dl oO 
gil gs dl oO) 
clea sell 


ID 
ADS) o Vk DZ 
5 We eae 
Le ibe 


1.0 
silo 
sled 


TD 
shOS6 WL AS 
shOG5 WL Aa 
gdboal ob 
pil sd oO) 


Adv 
10 255. 
10.255. 
10.255. 
ORE or 
ORDO 


Adv 
ORD or 
10.255. 
10.255 . 
10.255. 
10,255. 
10.255. 


Adv 
10.255. 
10,255. 
10.255. 
ORE or 


Area 0.0.0.1 


Iie Te 


70 


eels 
V1 5 
TAs 
ills 


o AOS! 
242 
242 
242 
242 


Area 0.0.0.2 


IRE Te 


TAL 


rele. 
Hake, 
eles 
Tals 
eles 


oe 

242 
242 
242 
242 
242 


acams Ur Or Ons 


RUG Ie 


ilk 
FL 
vials 
vel 


9 DNS 
~242 
~242 
~242 


seq 
0x80000002 
0x80000002 
0x80000002 
0x80000002 
0x80000002 


seq 
x80000004 
x80000003 
x80000002 
x80000001 
x80000002 
x80000001 











Seq 
0x80000003 
0x80000003 
0x80000002 
0x80000001 


Age 
2M) 
214 
We 
7) 
ZL 


Age 
174 
ies; 
ys 
2A 
ia, 
222 


Age 
es) 
aie 
ia; 
ZA) 


Opt 

0x20 
0x20 
0x20 
0x20 
0x28 


Opt 

0x20 
0x20 
0x20 
0x20 
0x20 
0x28 


Opie 

0x20 
0x20 
0x20 
0x20 


Cksum 

0x4112 
Ox1llbl 
Ox6d72 
O0x607e 
0x73bd 


Cksum 

Oxd021 
Oxel91 
0x9c76 
Oxfeec 
Ox607e 
Oxe047 


Cksum 
0x3942 
Oxf37d 
Oxea orl 


Oxfeec 


Level of Output 


summary 


summary 


summary 


summary 


Len 


48 
48 
28 
28 
36 


Len 


36 
36 
2 
28 
28 
36 


Len 


36 
36 
32 
28 
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Summary *23 
NSSA 2S) 


gle 510) 
gdbg als al 


show ospf database 


10). 2995 P5442 
IW SZDD5 Hl 5 AA 


0x80000002 
0x80000001 


Ie 
Bae 


0x20 
0x28 


Ox6d72 
Oxeb3b 


28 
36 


The output for show ospf databse nssa with nssa-only configuration statement enabled at [edit 


policy-options policy-statement policy-name term term name then external], which clears P-bit on type 


7 LSA. 


user@host> show ospf database 


OSPF link state database, 


Type 
Router 11) 
Router *10 
Summary *23 
Summary *24 
NSSA 235 


OSPF link state database, 


Type 


Router LO), 
NewieSi IL), 
Network *23. 
Summary *12. 
Summary *24. 
NSSA OS) 5 


OSPF link state database, 


Type 
Router EQ) 


RewiES iL). 
Network *24. 
Summary *12. 
Summary *23. 
NSSA 233% 


TD 

52596 10,103 
sAOS5 WL Aa 
gio io @ 

gil gal oO) 

cil eeal sell 


oN 6) 
2585 V1 O2 
yoo) 5 Ul 6 Ba 
de ibeal 


AL 5 (0) 
sil. 
dod 
iD 

5D 5 WL Be 
2585 Wl BAe 


toiled 


1.50) 
5 dk5) 
ile 


show ospf database brief 


The output for the show ospf database brief command is identical to that for the show ospf database 
command. For sample output, see show ospf database on page 823. 


Adv 
10.255. 
10,255. 
10,255. 
10.255 . 
10.255. 


Adv 
10,255. 
10.255). 
ORE or 
1@ .255 . 
10,255. 
10.255. 


Adv 
ORAZ or 
10.255. 
10.255. 
10.255. 
10-255. 
10.255. 


IRIE IE 
10. 
ipl 
Wi. 
wale 
gels 


Rtr 
pl 
ples 
Hele 
eles 
WAL. 
ciple 


IRIE IE 
WAL. 
ipl 
Wi. 
ipl 
pls 
vale: 


Area 0.0.0.1 


110) s) 
242 
242 
242 
242 


Area 0.0.0.2 


De 

242 
242 
242 
242 
242 


Mecam Um Or Ons 


238 
242 
242 
242 
242 
242 


Seq 
0x80000002 
0x80000002 
0x80000002 
0x80000002 
0x80000002 


seq 
x8000000 
x8000000 
x8000000 
x8000000 
x8000000 
x8000000 














fr SS) te es) eS 


seq 
x8000000 
x8000000 
x8000000 
x8000000 
x8000000 
x8000000 














fr ks) ISS) eH) 


Age 
AUS) 
214 
eZ, 
177 
AL) 


Age 
174 
es; 
ys 
AL 
ia, 
222 


Age 
ys) 
ay, 
ae, 
27) 
We 
Zoe. 


Opie 

0x20 
0x20 
0x20 
0x20 
0x20 


Opt 

0x20 
0x20 
0x20 
0x20 
0x20 
0x28 


Opie 

0x20 
0x20 
0x20 
0x20 
0x20 
0x20 


Cksum 

0x4112 
Ox1llbl 
Ox6d72 
0x607e 
0x73bd 


Cksum 
Oxd021 
Oxel 91 
0x9c76 
Oxfeec 
Ox607e 
Oxe047 


Cksum 
0x3942 
Oxf37d 
Oxea oil 
Oxfeec 
Ox6d72 
Oxeb3b 


Len 
48 
48 
28 
28 
36 


Len 
36 
36 
Be 
28 
28 
SiS 


Len 
36 
36 
SZ 
28 
28 
36 
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show ospf database detail 


user@host> show ospf database detail 


OSPF link state database, Area 0.0.0.1 
Type ID Adv Rtr Seq Age Opt Cksum Len 
Router LO 255, 10.103 10.255. 70, 103 0x80000002 261 0x20 0x4112 48 
lolics O20), Ilamk copie 2 
16 IO .255, fl 242, cata IZ, Myss PoumicwePeame (1) 
MO Sae Onan Ome © SiO mein citerteikcmmel| 
i¢l 12,1,1,0, cata 255,255.255.0, Wye Siculs (3) 
© Sane Oia O) eee) Sam Omani c texralaonmnl 
Robeeie “LO.255.,7L.ea2 10.255 .71 242 0x80000002 260 0x20 Oxllbl 48 
lolics) O23, Ilaiink eouimnic 2 
iC 10 .25957/0.103, cata 12,1,1.2, Wee PoimetorPoume (1) 
108 coulmec O, TOS © imeicieake 11 
acl 12,1,1,0, Caice 255,.255.255.0, Wise Sculo (3) 
TOS Ccomine O, TOS © meiereike 1 
Suimunsey “23), i. 1 oO 10.2555 71.242 0x80000002 218 0x20 O0x6d72 28 
MASE. 255.4951 525550 
1OS OO, meieieie: 1 
Summary *24.1.1.0 10-255. 71.242 0x80000002 223 0x20 0x607e 28 
MES 255.255.2550 
TOS Os0, mveicicsxe 11 
NSSA Soyo dls dal IO 255.71 242 0x80000002 263 0x28 Ox73bd 36 
MASK BIS c295 5.259.255) 
Iyioe 2, WOS OO, meee O, ive ackle 121,12, tag 0.0.0.0 




















OSPF link state database, Area 0.0.0.2 
Type ID Adv Rtr Seq Age Opt Cksum Len 
Router LO 255), IL. SZ 10.255 .571.452 0x80000004 220 Ox20) OxclOZl 36 
lomlics Os20), Jlaiink emoulinie AL 
16 Zoici loi, Cate 23,8 1,4, Wyo Wiesingait (2) 
1OS coum O, LOS © imeicieske: Al 
Ropeee “LO .255.7L.ga2 10.255 ..71 242 0x80000003 219 0x20 Oxel91 36 
folic Opxs}, ilsialke eoulaie iL 
ie@l 23,.l,1,il, data 2Z3cil.l.l, Uwee Uramenic (2) 
TO Smee OUntemnO)me © Sam Ominciteteacmmel 
Network *23.1.1.1 10.255. 71.242 0x80000002 2 Ox20) OR9C7G 32 
MASK 255.255. 25940 
attached router 10.255.71.242 
gincraciecl wemicer 10.2495. 71.52 
Simunsiey “12, i150 10. 255.5 71 22 0x80000001 263 0x20 Oxfeec 28 
MASK 2555455525550 
IOS OO, ameieieie. 1 
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Summary *24.1.1.0 10.255 .71 242 0x80000002 223 0x20 0x607e 28 
MAK 255.255 525940 
LOS OO, mneieieaye: AL 

NSSA wo dls 1 6 dl IO 6 2S)5 HL Bae 0x80000001 268 0x28 Oxe047 36 
mAs 255.295.259.255 
tyes 2, WOS Ox0, metric O, tie acklie 23,i1,1.,1, cag ©.0.0.0 


OSPF link state database, Area 0.0.0.3 
Type ID Adv Rtr Seq Age Opt Cksum Len 
Router LO. 259571 2S 10.255. 71.238 0x80000003 2a5 W220 O239E2Z 36 
lowlics OO, ism cowie IL 
ig 28 oi,lail, data 24.1l.1.2, yee Preamsiit. (2) 
TOS cominc O, TOS © meiere5ke 1 
Inewieee IO 255.571.2482 10 5255. 7/1 242 0x80000003 Das OWx20 Oxaesycl 36 
loalics} O23}, laine eoiuiaie iL 
a6 24,1, data 24.,l.il, Woe weeimsue (2) 
1OS comme O-, LOS © imeieresye 11 
Network *24.1.1.1 10.255 71.242 0x80000002 243 OWx20 Oxepy9l 32 
mS 25.2595 6255 40 
attached router 10.255.71.242 
gicreclaec wemiEesie 10).255. 711.238 
Siumimneiey ~i2., i, 1.0 10,255. 71.242 0x80000001 263 0x20 Oxfeec 28 
MES 255.255.2355 .50 
TOS Ox, mveieiesce: IL 
Simmey “25 5151.0 10 .255..71.242 0x80000002 BAL) O20) Wpxtsrel/2 2s) 
MAGE 255.2555 259)40 
sMO}S ian Ob; 40 aan i\— hon an oun l 
NSSA wad odio toil 10,255. 71 242 0x80000001 268 0x28 Oxeb3b 36 
mas 255.295.259.255 
iyee 2, WOS Ox0, metric 0, tic ackle 24.i1,1.1, cag @.0.0.0 


show ospf database summary 


user@host> show ospf database summary 


meee O.0 0.1% 
2 Router LSAs 
2 Summary LSAs 
1 NSSA LSAs 
meee OO.0.28 
2 Router LSAs 
Network LSAs 





1 
2 Summary LSAs 
1 NSSA LSAs 
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| show ospf3 database 


List of Syntax 
Syntax on page 828 
Syntax (EX Series Switches and QFX Series) on page 828 


Syntax 


show ospf3 database 

<brief | detail | extensive | summary> 
<advertising-router (address | self)> 

<area area-id> 

<external> 

<instance instance-name> 
<inter-area-prefix> 

<inter-area-router> 

<intra-area-prefix> 

<link> 

<link-local> 

<logical-system (all | logical-system-name)> 
<Isa-id Isa-id> 

<network> 

<nssa> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


<router> 


Syntax (EX Series Switches and QFX Series) 


show ospf3 database 

<brief | detail | extensive | summary> 
<advertising-router (address | self)> 
<area area-id> 

<external> 

<instance instance-name> 
<inter-area-prefix> 
<inter-area-router> 
<intra-area-prefix> 

<link> 

<link-local> 

<lsa-id Isa-id> 

<network> 

<nssa> 


<router> 
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Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option introduced in Junos OS Release 9.2. 

advertising-router (address | self) option introduced in Junos Relase 9.5. 

advertising-router (address | self) option introduced in Junos OS Release 9.5 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 


Description 
Display the entries in the OSPF version 3 (OSPFv3) link-state database, which contains data about link-state 
advertisement (LSA) packets. 


Options 


none—Display standard information about all entries in the OSPFv3 link-state database. 
brief | detail | extensive | summary—(Optional) Display the specified level of output. 


advertising-router (address | self)—(Optional) Display the LSAs advertised either by a particular routing 
device or by this routing device. 


area area-id—(Optional) Display the LSAs in a particular area. 
external—(Optional) Display external LSAs. 


instance instance-name—(Optional) Display all OSPF database information under the named routing 
instance. 


inter-area-prefix—(Optional) Display information about interarea-prefix LSAs. 
inter-area-router—(Optional) Display information about interarea-router LSAs. 
intra-area-prefix—(Optional) Display information about intra-area-prefix LSAs. 
link—(Optional) Display information about link LSAs. 

link-local—(Optional) Display information about link-local LSAs. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


Isa-id Isa-id—(Optional) Display the LSA with the specified LSA identifier. 
network—(Optional) Display information about network LSAs. 
nssa—(Optional) Display information about not-so-stubby area (NSSA) LSAs. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(Optional) Display information about the specified 
OSPFv3 realm, or address family. Use the realm option to specify an address family other than IPv6é 
unicast, which is the default. 


router—(Optional) Display information about router LSAs. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


| clear (ospf | ospf3) database | 783 


List of Sample Output 


show ospf3 database brief on page 835 
show ospf3 database summary on page 836 


Output Fields 
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Table 15 on page 830 lists the output fields for the show ospf3 database command. Output fields are listed 


in the approximate order in which they appear. 


Table 15: show ospf3 database Output Fields 


Field Name 


OSPF link state database, 
area area-number 


OSPF AS SCOPE link 
state database 


OSPF Link-Local link 
state database, interface 
interface-name 


area 


Type 


Adv Rtr 


Seq 


Field Description 


Entries in the link-state database for this area. 


Entries in the AS scope link-state database. 


Entries in the link-local link-state database for this interface. 


Area number. Area 0.0.0.0 is the backbone area. 


Type of link advertisement: Extern, InterArPfx, InterArRtr, IntraArPrx , 
Link, Network, NSSA, or Router. 


Link identifier included in the advertisement. An asterisk (*) preceding the 
identifier marks database entries that originated from the local routing 
device. 


Address of the routing device that sent the advertisement. 


Link sequence number of the advertisement. 


Level of Output 


brief detail extensive 


brief detail extensive 


brief detail extensive 


All levels 


brief detail extensive 


brief detail extensive 


brief detail extensive 


brief detail extensive 


Table 15: show ospf3 database Output Fields (continued) 


Field Name 


Age 


Cksum 


Len 


Field Description 


Time elapsed since the LSA was originated, in seconds. 


Checksum value of the LSA. 


Length of the advertisement, in bytes. 


Router (Router Link-State Advertisements) 


bits 


Options 


For Each Router Link 


Type 


Loc-if-id 


Nbr-if-id 


Nbr-rtr-id 


Metric 


Gen timer 


Aging timer 


Installed nn:nn:nn ago 


expires in nn:nn:nn 


sent nn:nn:nn ago 


Flags describing the routing device that generated the LSP. 


Option bits carried in the router LSA. 


Type of interface. The value of all other output fields describing a routing 
device interface depends on the interface’s type: 


e PointToPoint (1)—Point-to-point connection to another routing device. 
e Transit (2)—Connection to a transit network. 


e Virtual (4)—Virtual link. 


Local interface ID assigned to the interface that uniquely identifies the 
interface with the routing device. 


Interface ID of the neighbor's interface for this routing device link. 


Router ID of the neighbor routing device (for type 2 interfaces, the 
attached link’s designated router). 


Cost of the router link. 


How long until the LSA is regenerated, in the format hours:minutes:seconds. 


How long until the LSA expires, in the format hours:minutes:seconds. 


How long ago the route was installed, in the format hours:minutes:seconds. 


How long until the route expires, in the format hours:minutes:seconds. 


Time elapsed since the LSA was last transmitted or flooded to an adjacency 
or an interface, respectively, in the format hours:minutes:seconds. 
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Level of Output 


brief detail extensive 


brief detail extensive 


brief detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


Table 15: show ospf3 database Output Fields (continued) 


Field Name Field Description 


Ours Indicates that this is a local advertisement. 


Network (Network Link-State Advertisements) 
Options Option bits carried in the network LSA. 
Attached Router Router IDs of each of the routing devices attached to the link. Only routing 


devices that are fully adjacent to the designated router are listed. The 
designated router includes itself in this list. 


InterArPfx (Interarea-Prefix Link-State Advertisements) 


Prefix IPvé address prefix. 
Prefix-options Option bit associated with the prefix. 
Metric Cost of this route. Expressed in the same units as the interface costs in 


the router LSAs. When the interarea-prefix LSA is describing a route to 
a range of addresses, the cost is set to the maximum cost to any reachable 
component of the address range. 


Gen timer How long until the LSA is regenerated, in the format hours:minutes:seconds. 
Aging timer How long until the LSA expires, in the format hours:minutes:seconds. 
Installed nn:nn:nn ago How long ago the route was installed, in the format hours:minutes:seconds. 
expires in nn:nn:nn How long until the route expires, in the format hours:minutes:seconds. 
sent nn:nn:nn ago Time elapsed since the LSA was last transmitted or flooded to an adjacency 


or an interface, respectively, in the format hours:minutes:seconds. 


Ours Indicates that this is a local advertisement. 


InterArRtr (Interarea-Router Link-State Advertisements) 


Dest-router-id Router ID of the routing device described by the LSA. 


options Optional capabilities supported by the routing device. 
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Level of Output 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


detail extensive 


detail extensive 


Table 15: show ospf3 database Output Fields (continued) 


Field Name 


Metric 


Prefix 


Prefix-options 


Field Description 

Cost of this route. Expressed in the same units as the interface costs in 
the router LSAs. When the interarea-prefix LSA is describing a route to 
a range of addresses, the cost is set to the maximum cost to any reachable 
component of the address range. 


IPvé address prefix. 


Option bit associated with the prefix. 


Extern (External Link-State Advertisements) 


Prefix 


Prefix-options 


Metric 


Typen 


Aging timer 


Installed nn:nn:nn ago 


expires in nn:nn:nn 


sent nn:nn:nn ago 


IPvé address prefix. 


Option bit associated with the prefix. 


Cost of the route, which depends on the value of Type. 


Type of external metric: Type 1 or Type 2. 


How long until the LSA expires, in the format hours:minutes:seconds. 


How long ago the route was installed, in the format hours:minutes:seconds. 


How long until the route expires, in the format hours:minutes:seconds. 


Time elapsed since the LSA was last transmitted or flooded to an adjacency 
or an interface, respectively, in the format hours:minutes:seconds. 


Link (Link-State Advertisements) 


IPv6é-Address 


Options 


priority 


Prefix-count 


Prefix 


IPvé6 link-local address on the link for which this link LSA originated. 


Option bits carried in the link LSA. 


Router priority of the interface attaching the originating routing device 
to the link. 


Number of IPv6 address prefixes contained in the LSA. The rest of the 
link LSA contains a list of IPv6 prefixes to be associated with the link. 


IPvé address prefix. 


833 


Level of Output 


detail extensive 


extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


extensive 


extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 15: show ospf3 database Output Fields (continued) 


Field Name 


Prefix-options 


Gen timer 


Aging timer 


Installed nn:nn:nn ago 


expires in nn:nn:nn 


sent nn:nn:nn ago 


Ours 


Field Description 


Option bit associated with the prefix. 


How long until the LSA is regenerated, in the format hours:minutes:seconds. 


How long until the LSA expires, in the format hours:minutes:seconds. 


How long ago the route was installed, in the format hours:minutes:seconds. 


How long until the route expires, in the format hours:minutes:seconds. 


Time elapsed since the LSA was last transmitted or flooded to an adjacency 
or an interface, respectively, in the format hours:minutes:seconds. 


Indicates that this is a local advertisement. 


IntraArPfx (Intra-Area-Prefix Link-State Advertisements) 


Ref-Isa-type 


Ref-lsa-id 


Ref-router-id 


Prefix-count 


Prefix 


Prefix-options 


Metric 


Gen timer 


Aging timer 


Installed hh:mm:ss ago 


LSA type of the referenced LSA. 


e Router—Address prefixes are associated with a router LSA. 


e Network—Address prefixes are associated with a network LSA. 


Link-state ID of the referenced LSA. 


Advertising router ID of the referenced LSA. 


Number of IPv6 address prefixes contained in the LSA. The rest of the 
link LSA contains a list of IPv6 prefixes to be associated with the link. 


IPvé address prefix. 


Option bit associated with the prefix. 


Cost of this prefix. Expressed in the same units as the interface costs in 
the router LSAs. 


How long until the LSA is regenerated, in the format hours:minutes:seconds. 


How long until the LSA expires, in the format hours:minutes:seconds. 


How long ago the route was installed, in the format hours:minutes:seconds. 
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Level of Output 


detail extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


extensive 


extensive 


Table 15: show ospf3 database Output Fields (continued) 


Field Name 
expires in hh:mm:ss 


sent hh:mm:ss ago 


n Router LSAs 

n Network LSAs 

n InterArPfx LSAs 

n InterArRtr LSAs 

n IntraArPfx LSAs 
Externals 

n Extern LSAs 

Interface interface-name 


n Link LSAs 


| Sample Output 


Field Description 


show ospf3 database brief 


user@host> show ospf3 database brief 


OSPF3 link state database, 


Type ID 
Router 0. 
50) 5 
(0) 
50) 5 


(0) 


ROULEE 
InterArPfx 
InterArRtr 


SS jw ec S&S 


IntraArPfx 


OSPF3 link state database, 


Type ID 


je iei ian tan he 
PP NM FP PR 


Level of Output 


How long until the route expires, in the format hours:minutes:seconds. extensive 
Time elapsed since the LSA was last transmitted or flooded to an adjacency | extensive 
or an interface, respectively, in the format hours:minutes:seconds. 
Number of router LSAs in the link-state database. summary 
Number of network LSAs in the link-state database. summary 
Number of interarea-prefix LSAs in the link-state database. summary 
Number of interarea-router LSAs in the link-state database. summary 
Number of intra-area-prefix LSAs in the link-state database. summary 
Display of the external LSA database. summary 
Number of external LSAs in the link-state database. summary 
Name of the interface for which link-local LSA information is displayed. | summary 
Number of link LSAs in the link-state database. summary 
area 0.0.0.0 

Adv Rtr Seq Age Cksum Len 

LO) «25554535 0x80000003 885 Oxa697 40 

10 6 29645 9S 0x80000002 953 Obeeo77 40) 

10629954493 0x80000001 910 Oxb96f 44 

10 6 2dS 6459S 0x80000001 110) Obeail5s) Sz 

LO 255.4, 93} 0x80000002 432 Ox7/88£ 72 

area 0.0.0.1 
Adv Rtr Seq Age Cksum Len 
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Router 10) 0.510), 
Router OROR Orel: 
Network OR ORR 
limc@wauePin<e “0.010. i 
imei ins 1050) 41052 
NSSA ORO OReE 
LiMeHeVAIPiD (050) 010.1 


OSPF3 AS SCOPE link state database 
41D) 
OROR Opal: 


Type 


Exter 





Exter 


OSPF3 Link-Local link state databas 
41D) 


Type 
Link 


show ospf3 database summary 


user@host> show ospf3 database summary 


Area 


Area 
2 
1 
2 
1 


il 





Z 


Interface 


1 


Interface 





Interface 
1 Link 


n 


n 





“O50 os i 


"Os 0,U52 


OR OR Ores Or: 


Roucer 


LSAs 


InterArPfx LSAs 


InterArRtr LSAs 





IntraArPfx LSAs 


@.G50.i8 
LSAs 


Roucer 


Ne 


ALigt 


NSSA LSAs 


In 


rx 


twork 


LSAS 


terArPfx LSAs 





traArPfx LSAs 


Externals: 





ESE I0 





SAS 








Link 


gae-1/3/ 0.0% 
LSAs 

RO ORROR 

Sm yy ORAOns 
LSAS 


ALO) 
LO, 
LO) « 
SOF, 
AL(O) , 
ALO) 
ALO), 


Zoe 
ABS) 0 
DS 6 
DBS) o 
Zon 
ZS) o 
Zon 


Adv Rtr 


Sy SS Sy ES TSS VBS SS 


LO 25954 oD 
LO > 258)54593 


Adv Rtr 








LO 258 5459S 


393 0x80000003 916 
oO? 0x80000006 851 
OF 0x80000002 916 
393 0x80000002 ler 
> 93 0x80000002 62 
ot 0x80000002 SOZ 
| 0x80000006 851 
seq Age 
0x80000002 63 
0x80000001 910 

rface ge-1/3/0.0 

seq Age 
0x80000003 916 


Oxea40 
Oxc95b 
0x4598 
0xa980 
Oxd47e 
0x45ee 
Ox2£77 


Cksum 
0x9b86 
Oxe9e9 


Cksum 
Ox4dab 


Ss 


Ss 





Ss Ss 
DO © S& £& NY GS © 


Len 
44 
44 


Len 
64 
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| show (ospf | ospf3) interface 


List of Syntax 
Syntax on page 837 
Syntax (EX Series Switches and QFX Series) on page 837 


Syntax 


show (ospf | ospf3) interface 

<brief | detail | extensive> 

<area area-id> 

<interface-name> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 

<realm (ip4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switches and QFX Series) 


show (ospf | ospf3) interface 
<brief | detail | extensive> 
<area area-id> 
<interface-name> 

<instance instance-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

area option introduced in Junos OS Release 9.2. 

area option introduced in Junos OS Release 9.2 for EX Series switches. 
realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Display the status of OSPF interfaces. 


Options 


none—Display standard information about the status of all OSPF interfaces for all routing instances 
brief | detail | extensive—(Optional) Display the specified level of output. 
area area-id—(Optional) Display information about the interfaces that belong to the specified area. 


interface-name—(Optional) Display information for the specified interface. 
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instance instance-name—(Optional) Display all OSPF interfaces under the named routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 


particular logical system. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(OSPFv3 only) (Optional) Display information about 


the interfaces for the specified OSPFv3 realm, or address family. Use the realm option to specify an 
address family for OSPFv3 other than IPvé6 unicast, which is the default. 


Required Privilege Level 


view 


List of Sample Output 


show ospf interface brief on page 840 
show ospf interface detail on page 841 
show ospf3 interface detail on page 841 


Output Fields 


Table 16 on page 838 lists the output fields for the show (ospf | ospf3) interface command. Output fields 


are listed in the approximate order in which they appear. 


Table 16: show (ospf | ospf3) interface Output Fields 


Field Name 


Interface 


State 


Area 


DRID 


BDRID 


Nbrs 


Type 


Address 


Mask 


Prefix-length 


OSPF3-Intf-Index 


Field Description 


Name of the interface running OSPF version 2 or OSPF version 3. 


State of the interface: BDR, Down, DR, DRother, Loop, PtToPt, or Waiting. 


Number of the area that the interface is in. 


Address of the area's designated router. 


Backup designated router for a particular subnet. 


Number of neighbors on this interface. 


Type of interface: LAN, NBMA, P2MP, P2P, or Virtual. 


IP address of the neighbor. 


Netmask of the neighbor. 


(OSPFv3) IPvé6 prefix length, in bits. 


(OSPFv3) OSPF version 3 interface index. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 16: show (ospf | ospf3) interface Output Fields (continued) 


Field Name 


MTU 


Cost 


DR addr 


BDR addr 


Adj count 


Secondary 


Flood Reduction 


Priority 


Flood list 


Ack list 


Descriptor list 


Hello 


Dead 


Auth type 


Topology 


Field Description 

Interface maximum transmission unit (MTU). 

Interface cost (metric). 

Address of the designated router. 

Address of the backup designated router. 

Number of adjacent neighbors. 

Indicates that this interface is configured as a secondary interface for this 
area. This interface can belong to more than one area, but can be 
designated as a primary interface for only one area. 

Indicates that this interface is configured with flooding reduction. All 
self-originated LSAs from this interface are initially sent with the 
DoNotAge bit set. As a result, LSAs are refreshed only when a change 
Occurs. 


Router priority used in designated router (DR) election on this interface. 


List of link-state advertisements (LSAs) that might be about to flood this 
interface. 


Acknowledgment list. List of pending acknowledgments on this interface. 


List of packet descriptors. 


Configured value for the hello timer. 


Configured value for the dead timer. 


(OSPFv2) Authentication mechanism for sending and receiving OSPF 
protocol packets: 


e MD5—The MD5 mechanism is configured in accordance with RFC 2328. 
e None—No authentication method is configured. 


e Password—A simple password (RFC 2328) is configured. 


(Multiarea adjacency) Name of topology: default or name. 
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Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


detail extensive 


extensive 


extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 16: show (ospf | ospf3) interface Output Fields (continued) 


Field Name 


LDP sync state 


reason 


config holdtime 


IPSec SA name 


Active key ID 


Start time 


ReXmit 


Stub, Not Stub, or Stub 
NSSA 


Field Description 


(OSPFv2 and LDP synchronization) Current state of LDP synchronization: 
in sync, in holddown, and not supported. 


(OSPFv2 and LDP synchronization) Reason for the current state of LDP 
synchronization. The LDP session might be up or down, or adjacency 
might be up or down. 


(OSPFv2 and LDP synchronization) Configured value of the hold timer. 


If the state is not synchronized, and the hold time is not infinity, the 
remaining field displays the number of seconds that remain until the 
configured hold timer expires. 


(OSPFv2) Name of the IPSec security association name. 


(OSPFv2 and MD5) Number from 0 to 255 that uniquely identifies an 
MD5 key. 


(OSPFv2 and MDS) Time at which the routing device starts using an MD5 
key to authenticate OSPF packets transmitted on the interface on which 
this key is configured. To authenticate received OSPF protocol packets, 
the key becomes effective immediately after the configuration is 
committed. If the start time option is not configured, the key is effective 
immediately for send and receive and is displayed as Start time 1970 Jan 
01 00:00:00 PST. 


Configured value for the Retransmit timer. 


Type of area. 
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Level of Output 


extensive 


extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


| Sample Output 


show ospf interface brief 


user@host> show ospf interface brief 


BDR ID Nbrs 
O-0.0.0 al 


Iiae ae 
ait—5/ 1/0. 


State DR ID 


ORTOR Or) 


Area 


IPC Ole ORO ORG 








ge-2/3/0.0 DR OPORORG 192.168.4.16 
100.0 DR OPRORORNO) 192.168.4.16 
So = O/0/OmO Down OROR ORO ORO ORO 
so-6/0/1.0 PtToPt OPORIOPNO) OOM ORG 
so-6/0/2.0 Down Op Onn ORa 0.0.0.0 
so-6/0/3.0 PtToPt OPORORG 050.0.,0 

show ospf interface detail 

user@host> show ospf interface detail 
Interface State Area DE ID 
fe-0/0/1.0 BDR 0.0.0.0 192, 168,37 12 


ae 


eo Se) © Ss 


Aye LAN, seeigess 192 lO3.37 dil, Masi 255.255 295.243, IMitw 4460), 


DIR ache 192 169.37 ,12, BOR ackele 192,168.57 ,ii, Ach) coume 1, 

Hello 10, Dead 40, ReXmit 5, Not Stub 

tel O/27/aleeO) Pic Woe tc ORO ORs) ORIORO RO) 

Ives P22, Ackizass Wo0.0.0, MAS O.0.0.0, Mad 1500, Coste 2o04 
Adj count 0 

Hello 10, Dead 40, ReXmit 5, Not Stub 





Auth type: MD5, Active key ID 3, Start time 2002 Nov 19 10:00:00 PST 


IPsec SA Name: sa 


show ospf3 interface detail 


user@host> show ospf3 interface so-0/0/3.0 detail 


IME STeIE UCI) State Area DR-ID 
so-0/0/3.0 Pic Woe tc ORO ORs) 0.0.0.0 
Address fe80::2a0:a5ff£f:fe28:ldfc, Prefix-length 64 
OSPF3-Intf-index 1, Type P2P, MTU 4470, Cost 12, Adj-count 1 
Hello 10, Dead 40, ReXmit 5, Not Stub 


er we 1S SS 


LOS, 45 LS 


er ey ~ er = 


ey ie oe S&S 


Dieioreticy 26) 


OR CR OR Cm) 


BDR-ID 


W.0,0.0 
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BDR ID Nbrs 
10,259,245 .215 il 
Cost 40 


Nbrs 


842 


| show (ospf | ospf3) io-statistics 


List of Syntax 
Syntax on page 842 
Syntax (EX Series Switch and QFX Series) on page 842 


Syntax 


show (ospf | ospf3) io-statistics 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switch and QFX Series) 


show (ospf | ospf3) io-statistics 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display Open Shortest Path First (OSPF) input and output statistics. 


Options 
none—Display OSPF input and output statistics. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


| clear (ospf | ospf3) statistics | 794 


List of Sample Output 
show ospf io-statistics on page 843 


Output Fields 
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Table 17 on page 843 lists the output fields for the show ospf io-statistics command. Output fields are 
listed in the approximate order in which they appear. 


Table 17: show (ospf | ospf3) io-statistics Output Fields 


Field Name Field Description 


Packets read Number of OSPF packets read since the last time the routing 
protocol was started. 


average per run Total number of packets divided by the total number of times 
the OSPF read operation is scheduled to run. 


max run Maximum number of packets for a given run among all 
scheduled runs. 


Receive errors Number of faulty packets received with errors. 


| Sample Output 


show ospf io-statistics 


user@host> show ospf io-statistics 


Packets read: 7361, average per run: 1.00, max run: 1 
Receive errors: 


None 
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| show (ospf | ospf3) log 


List of Syntax 
Syntax on page 844 
Syntax (EX Series Switch and QFX Series) on page 844 


Syntax 


show (ospf | osfp3) log 

<instance instance-name> 

<logical-system (all | logical-system-name)> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 
<topology topology-name> 


Syntax (EX Series Switch and QFX Series) 


show (ospf | osfp3) log 
<instance instance-name> 


<topology topology-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
topology option introduced in Junos OS Release 9.0. 

topology option introduced in Junos OS Release 9.0 for EX Series switches. 
realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display the entries in the Open Shortest Path First (OSPF) log of SPF calculations. 


Options 


none—Display entries in the OSPF log of SPF calculations for all routing instances. 
instance instance-name—(Optional) Display entries for the specified routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


topology topology-name—(Optional) (OSPFv2 only) Display entries for the specified topology. 
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realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(OSPFv3 only) (Optional) Display entries for the 
specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


Required Privilege Level 
view 


List of Sample Output 
show ospf log on page 845 
show ospf log topology voice on page 846 


Output Fields 


Table 18 on page 845 lists the output fields for the show (ospf | ospf3) log command. Output fields are 
listed in the approximate order in which they appear. 


Table 18: show (ospf | ospf3) log Output Fields 


Field Name Field Description 

When Time, in weeks (w) and days (d), since the SPF calculation was 
made. 

Type Type of calculation: Cleanup, External, Interarea, NSSA, Redist, 


SPF, Stub, Total, or Virtuallink. 


Elapsed Amount of time, in seconds, that elapsed during the operation, 
or the time required to complete the SPF calculation. The start 
time is the time displayed in the When field. 


| Sample Output 


show ospf log 


user@host> show ospf log 








When Type Elapsed 
lw4d 17:25:58 Stub 0.000017 
lw4d 17:25:58 SEE 0.000070 
lw4d 17:25:58 Stub 0.000019 
UWACL LIS 25s 58 Interarea 0.000054 
UwACl LVS 258 Sis) External 0.000005 
InAcl IL e258 58 Cleanup 0.000203 








lw4d 
lw4d 
lw4d 
lw4d 
lw4d 
lw4d 
lw4d 
lw4d 
lw4d 


ys 
Ls 
Tis: 
alse 
alii 
IES 
alii 
alvigs 
13 


Pore 
24: 
24: 
24: 
24: 
24: 
24: 
24: 
24: 





Ss 


Ss 





Total 
SPH 
Stub 
SPH 
Stub 


Interarea 





External 
Cleanup 
Mowaul 


show ospf log topology voice 


SS Se ec eo f& 2S |] ©& 


-000537 
-00OL25 
-000017 
.000100 
.000016 
-000056 
-000005 
. 000238 
-000600 


user@host> show ospf log topology voice 


Topology voice SPF log: 
































Last instance of each event typ 
When Type Elapsed 
OW SOG s Lib SEI 0.000116 
00:06:11 Stub 0.000114 
00:06:11 Interarea 0.000126 
OOF OGesellsls External 0.000067 
00:06:11 NSSA 0.000037 
COMO Geer Cleanup 0.000186 

Maximum length of each typ 
When Type Elapsed 
00:13:43 SPE 0.000140 
IOS Shs Sis) Stub 0.000116 
OW silsis ats) Interarea 0.000128 
OO iss 3S) External 0.000075 
ONO) g 1LS)3 Sits) NSSA 0.000039 
OW gilss 5s) Cleanup 0.000657 

Last 100 events 
When Type Elapsed 
OO s se Bs SPE 0.000090 
Og 13}8 Ss) Stub 0.000041 
OOS Ss Interarea OR OOOMEZS 
Og Ss Ss) External 0.000040 
OMe iss Ss NSSA 0.000038 
OORDS 5S Cleanup 0.000657 
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| show (ospf | ospf3) neighbor 


List of Syntax 
Syntax on page 848 
Syntax (EX Series Switches and QFX Series) on page 848 


Syntax 


show (ospf | ospf3) neighbor 

<brief | detail | extensive> 

<area area-id> 

<instance (all | instance-name)> 

<interface interface-name> 

<logical-system (all | logical-system-name)> 

<neighbor> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switches and QFX Series) 


show (ospf | ospf3) neighbor 
<brief | detail | extensive> 
<area area-id> 

<instance (all | instance-name)> 
<interface interface-name> 
<neighbor> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

instance all option introduced in Junos OS Release 9.1. 

instance all option introduced in Junos OS Release 9.1 for EX Series switches. 

area, interface, and realm options introduced in Junos OS Release 9.2. 

area and interface options introduced in Junos OS Release 9.2 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 

Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Display information about OSPF neighbors. 


CPU utilization might increase while the device learns its OSPF neighbors. We recommend that you use 
the show (ospf | ospf3) neighbor command after the device learns and establishes OSPF neighbor 
adjacencies. Depending on the size of your network, this might take several minutes. If you receive a 
“timeout communicating with routing daemon” error when using the show (ospf | ospf3) neighbor command, 
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wait several minutes before attempting to use the command again. This is not a critical system error, but 
you might experience a delay in using the CLI. 


Options 


none—Display standard information about all OSPF neighbors for all routing instances. 
brief | detail | extensive—(Optional) Display the specified level of output. 
area area-id—(Optional) Display information about the OSPF neighbors for the specified area. 


instance (all | instance-name)—(Optional) Display all OSPF interfaces for all routing instances or under the 
named routing instance. 


interface interface-name—(Optional) Display information about OSPF neighbors for the specified logical 
interface. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


neighbor—(Optional) Display information about the specified OSPF neighbor. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(OSPFv3 only) (Optional) Display information about 
the OSPF neighbors for the specified OSPFv3 realm, or address family. Use the realm option to specify 
an address family for OSPFv3 other than IPv6 unicast, which is the default. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear (ospf | ospf3) neighbor | 790 


List of Sample Output 

show ospf neighbor brief on page 852 
show ospf neighbor detail on page 852 
show ospf neighbor extensive on page 852 


Output Fields 
Table 19 on page 849 lists the output fields for the show (ospf | ospf3) neighbor command. Output fields 
are listed in the approximate order in which they appear. 


Table 19: show (ospf | ospf3) neighbor Output Fields 


Field Name Field Description Level of Output 


Address Address of the neighbor. All levels 
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Table 19: show (ospf | ospf3) neighbor Output Fields (continued) 


Field Name 


Interface 


State 


Pri 


Dead 


Field Description Level of Output 
Interface through which the neighbor is reachable. All levels 
State of the neighbor: All levels 


e Attempt—Valid only for neighbors attached to nonbroadcast networks. 
It indicates that no recent information has been received from the 
neighbor, but that a more concerted effort must be made to contact 
the neighbor. 


e Down-Initial state of a neighbor conversation. It indicates that no 
recent information has been received from the neighbor. Hello packets 
might continue to be sent to neighbors in the Down state, although at 
a reduced frequency. 


e Exchange—Routing device is describing its entire link-state database 
by sending database description packets to the neighbor. Each packet 
has a sequence number and is explicitly acknowledged. 


e ExStart—First step in creating an adjacency between the two 
neighboring routing devices. The goal of this step is to determine which 
routing device is the master, and to determine the initial sequence 
number. 


e Full—Neighboring routing devices are fully adjacent. These adjacencies 
appear in router link and network link advertisements. 


e Init—A hello packet has recently been sent by the neighbor. However, 
bidirectional communication has not yet been established with the 
neighbor. This state may occur, for example, because the routing device 
itself did not appear in the neighbor's hello packet. 

e Loading—Link-state request packets are sent to the neighbor to acquire 


more recent advertisements that have been discovered (but not yet 
received) in the Exchange state. 


e 2Way—Communication between the two routing devices is bidirectional. 
This state has been ensured by the operation of the Hello Protocol. 
This is the most advanced state short of beginning adjacency 
establishment. The (backup) designated router is selected from the set 
of neighbors in state 2Way or greater. 


Router ID of the neighbor. All levels 


Priority of the neighbor to become the designated router. All levels 


Number of seconds until the neighbor becomes unreachable. All levels 


Table 19: show (ospf | ospf3) neighbor Output Fields (continued) 


Field Name 
Link state 
acknowledgment 
list 

Link state 


retransmission 
list 


Neighbor-address 


area 


OSPF3-Intf-Index 


opt 


DR or DR-ID 


BDR or BDR-ID 


Up 


adjacent 


SPRING 
Adjacency Labels 


Label 


Flags 


Field Description 


Number of link-state acknowledgments received. 


Total number of link-state advertisements retransmitted. For extensive 


output only, the following information is also displayed: 


e Type—Type of link advertisement: ASBR, Sum, Extern, Network, NSSA, 
OpagArea, Router, or Summary. 


e LSA ID—LSA identifier included in the advertisement. An asterisk 
preceding the identifier marks database entries that originated from 
the local routing device. 


e Adv rtr—Address of the routing device that sent the advertisement. 


e Seq—Link sequence number of the advertisement. 


(OSPFv3 only) If the neighbor uses virtual links, the Neighbor-address is 
the site-local, local, or global address. If the neighbor uses a physical 
interface, the Neighbor-address is an IPvé6 link-local address. 

Area that the neighbor is in. 

(OSPFv3 only) Displays the OSPFv3 interface index. 

Option bits received in the hello packets from the neighbor. 

Address of the designated router. 

Address of the backup designated router. 

Length of time since the neighbor came up. 


Length of time since the adjacency with the neighbor was established. 


Segment routing in networking adjacency labels. 


NOTE: Displayed only when segment routing is enabled 


Segment routing label. 


Segment routing flags. Flags VL indicate value and local. 


Level of Output 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 
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| Sample Output 


show ospf neighbor brief 


user@host> show ospf neighbor brief 


Address Tomiterts 
192.168.254.225 itxgos 0 
192 163.254.5230 ioxos 0 
192 168.254.2295 ios). 0 
10.1.1 129 £xpZ.0 
ALG) alg dl, 1Shib fxp2.0 
10,626 i fxp1.0 

Ot Zoe fxp0.0 





show ospf neighbor detail 


user@host> show ospf neighbor detail 


Address Interface 

10.0.6.60 Le=1/2/0.12 
Meee, WO .0.0.0, osc Ox52, DR O.0.0.0, 
Up MASH SS AW araGulacenianAS ome 4 
SPRING Adjacency Labels: 


Label Flags 
OSES VL 
100,10. 7€ Le-1/2/0.,14 


Avcan0POr0m0 Ope Oso 2 DR OOOO, 
Up EZ SES 4 aacsiacenia. 5 soo 4) 
SPRING Adjacency Labels: 


Label Flags 


ZOOS VL 


show ospf neighbor extensive 


user@host> show ospf neighbor extensive 


Interface 
Gea-1L/2/10.1 


Address 
IO. B pdb a2 


State 
2Way 

fake 
Ful 
Fake 
Ful 
ful 





PPP PP PR 


Ful 


State 
iaudL IL 


OR 
10). 
ILO) 
LO). 
KOR 
LO) 5 
10), 


BDRSOR OR ORO) 


lalla 


BDRSOROM ORO 


State 
Full 


ZOO) 6 
ARNO) 5 
ZBI) 6 
BNO) 5 
ZB) 
ZS) 6 
ZB) 


ID 


od dc OO 


Lois. 10 


106) 
LO Sesto 


240. 
240. 
240. 
240. 
240. 
240. 
240. 


32 


35) 


12 


dal 


10 


IDaeat 
128 
LAS 
128 
AS 
128 
LARS) 
zo 


Dead 

36 

38 

8) 

37 

38 

32 

38) 
Pri Dead 
ANS) 38 
128 37 
Pri Dead 
ANS) 23 


852 


853 


area O.0.0,1, oot Oxt2, IDR 10.5,1.2, BOR 10.5, 1, 
Up 06:09:42, adjacent 05:17:50 


Link state retransmission list: 




















Type LSA ID Adv rtr Seq 
Summary 10.8.56.0 W723 25527 182 0x8000004d 
Router IO. S.1. 94) 10.1594 0x8000005c 
Network 10.5.24.2 10,551.94 0x80000036 
Summary 10.8.57.0 VTA. 29527 82 0x80000024 
Extern 1510.90 0 10 .851,2 0x80000041 
Extern 1, 4,102.0) 10,6,1.2 0x80000041 
Router 10.5 .L.19€ 10,5,1,190 Ox8000005£ 
Network 10.5.48.2 10,5,1,190 0x8000003d 
Summary 10.8.58.0 VT2.29 527 82 0x8000004d 
Extern 1,10.91.0 10.3,1.2 0x80000041 
Extern 1.4.110.0 10.651 ,2 0x80000041 
Router 10 .5-1,18 10,5,1.518 Ox8000005£ 
Network 10.5.5.2 10,551,182 0x80000033 
Summary 10.8.59.0 V2 cADo2T 682 0x8000003a 
SODA (sC~ Wah) A Os BP OPA) V2.2 9524 82 0x80000025 

10. 5610.2 ge-1/2/0.10 ExStart 10,551.38 128 38 








area WO 0.0,1, oot O42, DR 1O,.5,10.2, BR 105.10. 
Up 06:09:42 


master, seq Oxacl530f£8, rexmit DBD in 2 sec 





rexmit LSREQ in 0 sec 
IO. GolL.2 ge-1/2/0.11 ioL AL 10.561 .42 128 33) 
area O.0.0,1, oot Ox#2, IDR 10,511.24, BID WO ,5,11, il 
Up 06:09:42, adjacent 05:27:00 
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| show (ospf | ospf3) overview 


List of Syntax 
Syntax on page 855 
Syntax (EX Series Switch and QFX Series) on page 855 


Syntax 


show (ospf | ospf3) overview 

<brief | extensive> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switch and QFX Series) 


show (ospf | ospf3) overview 
<brief | extensive> 
<instance instance-name> 


Release Information 

Command introduced in Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option introduced in Junos OS Release 9.2. 

Database protection introduced in Junos 10.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Display Open Shortest Path First (OSPF) overview information. 


Options 


none—Display standard information about all OSPF neighbors for all routing instances. 
brief | extensive—(Optional) Display the specified level of output. 
instance instance-name—(Optional) Display all OSPF interfaces under the named routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(Optional) (OSPFv3 only) Display information about 
the specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


Required Privilege Level 


view 


List of Sample Output 


show ospf overview (without SRGB) on page 858 

show ospf overview (with SRGB) on page 859 

show ospf overview (With Database Protection) on page 860 
show ospf3 overview (With Database Protection) on page 860 


show ospf overview extensive on page 861 


Output Fields 


Table 20 on page 856 lists the output fields for the show ospf overview command. Output fields are listed 


in the approximate order in which they appear. 


Table 20: show ospf overview Output Fields 


Field name 


Instance 


Router ID 


Route table index 


Configured overload 


Topology 


Prefix export count 


Full SPF runs 


SPF delay 


SPF holddown 


SPF rapid runs 


LSA refresh time 


SPRING 


Field Description 

OSPF routing instance. 

Router ID of the routing device. 

Route table index. 

Overload capability is enabled. If the overload timer is also configured, 
display the time that remains before it is set to expire. This field is not 
displayed after the timer expires. 

Topology identifier. 

Number of prefixes exported into OSPF. 

Number of complete Shortest Path First calculations. 


Delay before performing consecutive Shortest Path First calculations. 


Delay before performing additional Shortest Path First (SPF) calculations 
after the maximum number of consecutive SPF calculations is reached. 


Maximum number of Shortest Path First calculations that can be performed 
in succession before the hold-down timer begins. 


Refresh period for link-state advertisement (in minutes). 


Source protocol routing in networking: enable or disable. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


Table 20: show ospf overview Output Fields (continued) 


Field name 


Node Segments 


Ipv4 Index 


Index Range 


Node Segment Blocks 
Allocated 


Database protection 
state 


Warning threshold 


Non self-generated LSAs 


Ignore time 


Reset time 


Ignore count 


Restart 


Restart duration 


Restart grace period 


Graceful restart helper 


mode 


Restart-signaling helper 
mode 


Helper mode 


Field Description 


Nodes of source protocol routing in networking:enable or disable. 


Ipv4 Index. 


lpv4 Index range. 


Details about node segment blocks. 


Current state of database protection. 


Threshold at which a warning message is logged (percentage of maximum 


LSA count). 


Number of LSAs whose router ID is not equal to the local router ID: 
Current, Warning (threshold), and Allowed. 


How long the database has been in the ignore state. 


How long the database must stay out of the ignore or isolated state before 
it returns to normal operations. 


Number of times the database has been in the ignore state: Current and 
Allowed. 


Graceful restart capability: enabled or disabled. 


Time period for complete reacquisition of OSPF neighbors. 


Time period for which the neighbors should consider the restarting routing 
device as part of the topology. 


(OSPF v2) Standard graceful restart helper capability (based on RFC 3623): 
enabled or disabled. 


(OSPFv2) Restart signaling-based graceful restart helper capability (based 
on RFC 4811, RFC 4812, and RFC 4813): enabled or disabled. 


(OSPFv3) Graceful restart helper capability: enabled or disabled. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 
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Table 20: show ospf overview Output Fields (continued) 


Field name 


Trace options 


Trace file 


Area 


Stub type 


Authentication Type 


Area border routers 


Neighbors 


Field Description 


OSPF-specific trace options. 


Name of the file to receive the output of the tracing operation. 


Area number. Area 0.0.0.0 is the backbone area. 


Stub type of area: Normal Stub, Not Stub, or Not so Stubby Stub. 


Type of authentication: None, Password, or MD5. 


NOTE: The Authentication Type field refers to the authentication 
configured at the [edit protocols ospf area area-id] level. Any 


authentication configured for an interface in this area will not affect the 


value of this field. 


Number of area border routers. 


Number of autonomous system boundary routers. 


| Sample Output 


show ospf overview (without SRGB) 


user@host> show ospf overview 


master 
LO); 259.5245 56 


Route table index: 0 


instance, 
Router ID: 
Configured overload, expires in 118 seconds 


LSA refresh time: 50 minutes 














SPRING: Enabled 

Node Segments: Enabled 

Ipv4 Index 10, Index Range: 2048 

Node Segment Blocks Allocated: 

Siceusc Inve, &£ OW, Sawa 256, Label-Range: [ 802048, 802303 ] 
Start Index 2G, Salve 256, Label-Range: [ 802304, 802559 |] 
Start Index Sie, Size 256, Label-Range: [ 802560, 802815 ] 
Start Index 768, Size 256, Label-Range: [ 802816, 803071 ] 
Start Index 1024, Siiwae Ax, lyalysil—Renees | sOsO72, eOsg2y | 
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Level of Output 


extensive 


extensive 


All levels 


All levels 


All levels 


All levels 


All levels 











Area border routers: 





Neighbors 


Up (in full state): 
(20) (0) 


Topology: default 
Prefix export count: 
inBuLl (Swe iewinss IL 
SPF delay: 


0.200000 sec, 


show ospf overview (with SRGB) 


user@host> show ospf overview 


Instance: Master 
Router ID: 
Route table index: 


LSA refresh time: 


Traffic engineering 


SPRING: Enabled 





HO) 5 1), 10), Le 


Topology: default 


SRGB Config Range 








Start Index LAS), Salwae 256, Label-Range: 
Start Index 1536, Size 256, Label-Range: 
Start Index 1792, Size 256, Label-Range: 
Restart: Enabled 
Restart duration: 20 sec 
Restart grace period: 40 sec 
Helper mod nabled 
meses O.050.0 
Stub type: Not Stub 
Authentication Type: None 


0, AS boundary routers 


0 


0 


SPF holddown: 


50 minutes 


SRGB Start-—-Label 1000, SRGB Index-Range 
SRGB Block Allocation: Success 
SRGB Start Index 1000, SRGB Size 2000, 
Node Segments: Enabled 
Ipv4 Index 1000 
Post Convergence Backup: Disabled 
meses O.050.0 
Stub type: Not Stub 
Authentication Type: None 





Area border routers: 0, 


Neighbors 
ij (aim ull sieareS)) 2 
(20D) @))) 


Prefix export count: 0 


AS boundary routers: 


3 


5 sec, 


[ 803328, 
[ 803584, 
[ 803840, 


3B 0) 


2000 


Label-—Range: 


0 


SPF rapid runs: 


[ 


803583 ] 
803839 ] 
804095 ] 


1000, 


S 


Zoo9 


] 
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mui SP wonass 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 





Backup SPF: Enabled, Remote Backup calculation enabled 


show ospf overview (With Database Protection) 


user@host> show ospf overview 


inisizane cr memals tees 
Romeer IDE LO.255), Wile, 208) 
Route table index: 0 
LSA refresh time: 50 minutes 
Traffic engineering 


Restart: Enabled 





Restart duration: 180 sec 


Restart grace period: 210 sec 





Graceful restart helper mode: Enabled 





Restart-signaling helper mode: Enabled 
Database protection state: Normal 


Warning threshold: 70 percent 





Non self-generated LSAs: Current 582, Warning 700, Allowed 1000 
Ignore time: 30, Reset time: 60 
Ignore count: Current 0, Allowed 1 

Mmesere 50,050 
Stub type: Not Stub 


Authentication Type: None 





Area border routers: 0, AS boundary routers: 0 
Neighbors 
Us (aim uli SiceeS) s 150) 
Topology: default (ID 0) 
Prefix export count: 0 
FLL See mums 7/0 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


show ospf3 overview (With Database Protection) 


user@host> show ospf3 overview 


instance: Master 
inoweeze IDS 10), 255), 112, 126) 
Route table index: 0 


LSA refresh time: 50 minutes 
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Database protection state: Normal 
Warning threshold: 80 percent 
Non self-generated LSAs: Current 3, Warning 8, Allowed 10 
Ignore time: 30, Reset time: 60 
Ignore count: Current 0, Allowed 2 
Meee O505050 
Stub type: Not Stub 
Area border routers: 0, AS boundary routers: 0 
Neighbors 
Uo (aim wl States) s a 
Topology: default (ID 0) 
Prefix export count: 0 
GIL Sri wumss 7 
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 
Backup SPF: Not Needed 


show ospf overview extensive 


user@host> show ospf overview extensive 


iiiSizciie Sr menaicie cits 
Rowear Ig ei. i. Ids 
Route table index: 0 
Full SPF runs: 13, SPF delay: 0.200000 sec 
LSA refresh time: 50 minutes 
Restart: Disabled 


Trace options: lsa 











Trace file: /var/log/ospf size 131072 files 10 
Area: 0.0.0.0 
Stub type: Not Stub 


Authentication Type: None 





Area border routers: 0, AS boundary routers: 0 
Neighbors 
US (am full state): J 
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| show (ospf | ospf3) route 


List of Syntax 
Syntax on page 862 
Syntax (EX Series Switch and QFX Series) on page 862 


Syntax 


show (ospf | ospf3) route 

<brief | detail | extensive> 

<abr | asbr | extern | inter | intra> 

<destination> 

<instance (default | ipv4-multicast | instance-name)> 
<logical-system (default | ipv4-multicast | logical-system-name)> 
<network> 

<no-backup-coverage> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 
<router> 

<topology (default | ipv4-multicast | topology-name)> 
<transit> 


Syntax (EX Series Switch and QFX Series) 


show (ospf | ospf3) route 

<brief | detail | extensive> 

<abr | asbr | extern | inter | intra> 

<destination> 

<instance instance-name 

<network> 

<no-backup-coverage> 

<router> 

<topology (default | ipv4-multicast | topology-name)> 
<transit> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
topology option introduced in Junos OS Release 9.0. 

realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display the entries in the Open Shortest Path First (OSPF) routing table. 
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Options 
none—Display standard information about all entries in the OSPF routing table for all routing instances 
and all topologies. 


destination—Display routes to the specified IP address (with optional destination prefix length). 
brief | detail | extensive—(Optional) Display the specified level of output. 

abr—(Optional) Display routes to area border routers. 

asbr—(Optional) Display routes to autonomous system border routers. 

extern—(Optional) Display external routes. 

inter—(Optional) Display interarea routes. 

intra—(Optional) Display intra-area routes. 


instance (default | ipv4-multicast | instance-name)—(Optional) Display entries for the default routing 
instance, the IPv4 multicast routing instance, or for the specified routing instance. 


logical-system (default | ipv4-multicast | logical-system-name)—(Optional) Perform this operation on the 
default logical system, the IPv4 multicast logical system, or on a particular logical system. 


network—(Optional) Display routes to networks. 


no-backup-coverage—(Optional) Display routes with no backup coverage. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(OSPFv3 only) (Optional) Display entries in the 
routing table for the specified OSPFv3 realm, or address family. Use the realm option to specify an 
address family for OSPFv3 other than IPvé6 unicast, which is the default. 


router—(Optional) Display routes to all routers. 


topology (default | ipv4-multicast | topology-name)—(OSPFv2 only) (Optional) Display routes for the default 
OSPF topology, IPv4 multicast topology, or for a particular topology. 


transit—(Optional) (OSPFv3 only) Display OSPFv3 routes to pseudonodes. 


Required Privilege Level 
view 


List of Sample Output 

show ospf route on page 865 

show ospf route extensive on page 866 
show ospf3 route on page 866 

show ospf route topology voice on page 867 


Output Fields 
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Table 21 on page 864 list the output fields for the show (ospf | ospf3) route command. Output fields are 


listed in the approximate order in which they appear. 


Table 21: show (ospf | ospf3) route Output Fields 


Field Name 


Topology 


Prefix 


Path type 


Route type 


NH Type 


Metric 


NH-interface 


NH-addr 


NextHop Interface 


Nexthop addr/label 


Area 


Field Description 


Name of the topology. 


Destination of the route. 


How the route was learned: 


e Inter—Interarea route 
e Ext1—External type 1 route 
e Ext2—External type 2 route 


e Intra—Intra-area route 
The type of routing device from which the route was learned: 


e AS BR—Route to AS border router. 

e Area BR—Route to area border router. 

e Area/AS BR—Route to router that is both an Area BR and AS BR. 
e Network—Network router. 

e Router—Route to a router that is neither an Area BR nor an AS BR. 


e Transit—(OSPFv3 only) Route to a pseudonode representing a transit 
network, LAN, or nonbroadcast multiaccess (NBMA) link. 


e Discard—Route to a summary discard. 


Next-hop type: LSP or IP. 


Route's metric value. 


(OSPFv3 only) Interface through which the route's next hop is reachable. 


(OSPFv3 only) IPv6é address of the next hop. 


(OSPFv2 only) Interface through which the route's next hop is reachable. 


(OSPFv2 only) If the NH Type is IP, then it is the address of the next hop. 


If the NH Type is LSP, then it is the name of the label-switched path. 


Area ID of the route. 


Output Level 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


detail 


Table 21: show (ospf | ospf3) route Output Fields (continued) 


Field Name 
Origin 


Type 7 


P-bit 


Fwd NZ 


optional-capability 


priority 


BGP-ORR Generation-ID 


| Sample Output 


show ospf route 


Field Description 


Router from which the route was learned. 


Route was learned through a not-so-stubby area (NSSA) link-state 
advertisement (LSA). 


Route was learned through NSSA LSA and the propagate bit was set. 


Forwarding address is nonzero. Fwd NZ is only displayed if the route is 
learned through an NSSA LSA. 


Optional capabilities propagated in the router LSA. This field is in the 
output for intra-area router routes only (when Route Type is Area BR, AS 
BR, Area/AS BR, or Router), not for interarea router routes or network 
routes. Three bits in this field are defined as follows: 


e 0x4 (V)—Routing device is at the end of a virtual active link. 
e Ox2 (E)—Routing device is an autonomous system boundary router. 


e Ox1 (B)—Routing device is an area border router. 
The priority assigned to the prefix: 


e high 
e medium 


e low 


NOTE: The priority field applies only to routes of type Network. 


Display the BGP-ORR generation identifier of the main OSPF route. This 
field is shown only for non-zero values. 


user@host> show ospf route 


Topology default Route Table: 


Prefix 


Path Route NH Metric NextHop Nexthop 


865 


Output Level 


detail 


detail 


detail 


detail 


detail 


detail 


extensive 








802068 


802078 


802088 


802098 


802108 


802118 


802118 


CO e 2 


lL WO/ 32 


Lo WOss2 


080/32 


80/32 


(S=0) 


(S=0) 


(S=0) 


(S=0) 


(S=0) 


(S=0) 


Type 


Iione eel 


leratertach 


inne 1 


eraitesrarch 


Heratesrach 


Ihione 12% 


Intra 


Intra 


Minne 12% 


leraestach 


leratesrach 





ine 16% 


show ospf route extensive 


Type 
Network 


Network 


etwork 


Network 


Network 


etwork 


Network 


Network 


etwork 


Network 


Network 








etwork 


user@host> show ospf route extensive 


Topology default Route Table: 


Pig eeese 


ores eel 


area 0.0.0.0, 


Leidgls 


area 0.0.0.0, 


1 


If 32 





Path 


Lype 
Intra 


Pacra 


BGP-ORR generation-id: 1 


show ospf3 route 


user@host> show ospf3 route 


houre 


Type 
ROULer 


Owigalia 1. it. il, 


Network 


Origiim L,i.i,i, 


Type 
Spring 
kup SPRING 


kup LSP 


kup SPRING 





kup IP 


Spring 


Bkup MPLS 


Bkup MPLS 


Bkup MPLS 


Bkup MPLS 


Bkup MPLS 


Bkup MPLS 























Bkup MPLS 


NH Metric 


iype: 
IP 


optional-capability 


IE? 


priority medium 














Interface 
ea / 2/0514 
lie 1/2/ 0.12 
e=1/ 2/0. 14 
ete 0/ 2y/ Ona 
le-1/2/0,12 
ie 1/27/04 
lea /2/ 0.12 
Lie 1 /2/ 0.14 
Tie 10 /2)// (0), as 
le=1/2/ 0.12 
lea / 2/0. 14 
Lie 1/2/ 0.12 
esi / 2/0514 
lre=-1/2/0.,12 
ete 0 2y/ Ohne 
Le=1/2/0.12 
lie / 2/0 14 
le=1/2/ 0.12 
lief 2/ 0.14 
le=1/2/0.12 
e=1//2/ 0, 14 
e=1/2/ 0.12 
NextHop 
Interface 
ge-0/0/2.0 
0x0 
ge-0/0/2.0 











Address/LSP 
LO.0.10., 70 
10 .0,6. 60 
LO.0.10, 70 
(null) 
10,0 ,10. 70 
HOR OR OroO) 
LOcO. 105 70 
10.0.6.60 
LOO. 10, 70 
10.0510. 70 
10.06.60) 
L0-0.10., 70 
10.0.6. 60 
LO.0.10., 70 
10.056. 60) 
10,0510. 70 
110) .0 55.60) 
LOO c1O. 70 
10.0.6. 60 
LOO, 105 70 
10,056.60) 
10.0510. 70 
10.056. 60) 
Nexthop 
Address/LSP 
AMO) I Al al 
LOel. dei 


866 



























































Prefix Path Route NH Metric NextHop 
Type Type Type Interface 
UO. 2dd6 7 IS) Intra Router ie ld 
NH-interface fe-0/0/2.0, NH-addr fe80::290:69ff:fe9b:e002 
10.255, 7L.13p0<0.0.2 
OR Aooraa one) Intra Router IP AMO) seeqoyil «AL 
area 0.0.0.0, origaia 10.255,245.i1 ositiomeal-caoalomility Os), 
UO -2Da 6246S Intra AS BR ie Lo igo, 3 
anee @.0.0.0, Origin 10,255.245.3 cstiomal—-cepaloniiicy Ob20), 
IM 255.4245), ly 32 Intra Network IP 40 fxpl1.1 
awee 0.0.0.0, origin 10,255,245. i, jorilermility Inalein 
10 .2555245) 2) 32 Intra Network IP @ 160.0 
eee O.0.0.0, origuin 10,255.245.2, jorederiity miecliuin 
10.255 4245). 3) 32 Intra Network IP i 1ESgo21, 8 
anuca OF 0,007 sonlgin LOZ45.37 priority low 
Intra Transit IP ald 
NH-interface fe-0/0/2.0 
192::168:222:84/126 Intra Network in il 
NH-interface fe-0/0/2.0 
alociels 37g IZ / 128) Intra Network IP 0 
NH-interface 100.0 
alocels 37g 13/128 Intra Network LSP 1 
NH-interface fe-0/0/2.0, NH-addr lsp-cd 
show ospf route topology voice 
user@host show ospf route topology voice 
Topology voice Route Table: 
Prefix Path Route NH Metric NextHop 
Type Type Type Interface 
10,255,852 Intra Router IP iS O= OF/-27/OrA0) 
10,255 8.3 Intra Router IP 2 so-0/2/0.0) 
10. 255.91 /32 Intra Network Iie ORero ORO 
10,255.98 .2/ 32 Intra Network IP il go-0/2/0.0 
10.255.8.3/ 32 Intra Network IP 2 s6-0/2/0 .0) 
18/2, 168) 58), 0/ 29) Intra Network IP 2S C= 01/27/00) 
192.168.8.44/30 Intra Network IP 2 g0-0/2/0.0 
NOZT NGS. Sk. 461/32 Intra Network IP i so-0/2/0.0 
192,168,848 30 Intra Network IP L so-0/2/i1.0 
192,168 .8,52,/ 30 Intra Network IP A so-0/2/ 0.0) 
192.168.9.44/30 Intra Network IP L so-0/2/0 40 
IS, IGE 4 45/32 Intra Network IP 2 s30-0/2/0 0) 


Nexthop 
addr/label 


LOZ 


Iz 


192 


U2 


Nexthop 
addr/label 


163} 536. 


IE! 5 SO. 


LOE). SO 


IOS 5 3 


17 


34 


7 


34 
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| show (ospf | ospf3) statistics 


List of Syntax 
Syntax on page 868 
Syntax (EX Series Switch and QFX Series) on page 868 


Syntax 


show (ospf | ospf3) statistics 

<instance instance-name> 

<logical-system (all | logical-system-name)> 

<realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)> 


Syntax (EX Series Switch and QFX Series) 


show (ospf | ospf3) statistics 
<instance instance-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

realm option introduced in Junos OS Release 9.2. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 
Display OSPF statistics. 


Options 


none—Display OSPF statistics for all routing instances. 
instance instance-name—(Optional) Display all statistics for the specified routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


realm (ipv4-multicast | ipv4-unicast | ipv6-multicast)—(Optional) (OSPFv3 only) Display all statistics for 
the specified OSPFv3 realm, or address family. Use the realm option to specify an address family for 
OSPF v3 other than IPv6 unicast, which is the default. 


Required Privilege Level 
view 
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RELATED DOCUMENTATION 


clear (ospf | ospf3) statistics | 794 


List of Sample Output 


show ospf statistics on page 870 
show ospf3 statistics on page 871 


Output Fields 


Table 22 on page 869 lists the output fields for the show (ospf | ospf3) statistics command. Output fields 


are listed in the approximate order in which they appear. 


Table 22: show (ospf | ospf3) statistics Output Fields 


Field Name 


Packet type 


Total Sent/Total 
Received 


Last 5 seconds Sent/Last 


5 seconds Received 


DBDs retransmitted 


LSAs flooded 


LSAs flooded high-prio 


LSAs retransmitted 


LSAs transmitted to nbr 


LSAs requested 


Field Description 


Type of OSPF packet. 


Total number of packets sent and received. 


Total number of packets sent and received in the last 5 seconds. 


Total number of database description packets retransmitted, 
and number retransmitted in the last 5 seconds. 


Total number of link-state advertisements flooded, and number 
flooded in the last 5 seconds. 


Total number of high priority link-state advertisements flooded, 
and number flooded in the last 5 seconds. 


A link-state advertisement is deemed a high priority if it has 
changed since it was last sent. 


Total number of link-state advertisements retransmitted, and 
number retransmitted in the last 5 seconds. 


Total number of link-state advertisements transmitted to a 
neighbor, and number transmitted in the last 5 seconds. 


Total number of link-state advertisements requested by 
neighboring devices, and number requested in the last 5 
seconds. 


Table 22: show (ospf | ospf3) statistics Output Fields (continued) 


Field Name Field Description 


LSAs acknowledged Total number of link-state advertisements acknowledged, and 
number acknowledged in the last 5 seconds. 


Flood queue depth Total number of entries in the extended queue. 


Total rexmit entries Total number of retransmission entries waiting to be sent from 
the OSPF routing instance. 


db summaries Total number of database description summaries waiting to 
be sent from the OSPF routing instance. 


Isreq entries Total number of link-state request entries waiting to be sent 
from the OSPF routing instance. 


Receive errors Number and type of receive errors. Some sample receive errors 
include: 
e mtu mismatches 
e no interface found 
e no virtual link found 
e nssa mismatches 
e stub area mismatches 


e subnet mismatches 


If there are no receive errors, the output displays none. 


| Sample Output 


show ospf statistics 


user@host> show ospf statistics 


Packet type Total Last 5 seconds 
Sent Received Sent Received 
Hello SL 14 z 2 
DbD 9 10 0 0 
LSReq 2 2 0 0 
LSUpdate 8 16 0 0 
LSAck 9 g) 0 0 
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DBDs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 





retransmitted 
flooded 

flooded high-prio 
retransmitted 
transmitted to nbr: 
requested 


acknowledged 


Flood queue depth 


Total rexmit entries 


db summaries 


lsreq entries 


Receive errors: 


862 no interface found 
WIS S AS ioe) Waliceell ilslioile ieyeiacl 


show ospf8 statistics 


user@host> show ospf3 statistics 


Packet type 





DBDs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 
LSAs 





LSReq 
LSUpdate 
LSAck 


Total 


Sent Received 


Hello 0 


DbD 


se =|) ww S&S 


retransmitted 
flooded 

flooded high-prio 
retransmitted 
transmitted to nbr: 
requested 


acknowledged 


Flood queue depth 


Total rexmit entries 


db summaries 


lsreq entries 


S 2 S&S & 


aS oe 2 & 


So oe 2 & 





Falsit 
Falsit 
last 
last 
last 
fast 


last 


(Gn Gl Gal Ga GGG) 


seconds 
seconds 
seconds 
seconds 
seconds 
seconds 


seconds 


Last 5 seconds 


Sent 


0 
0 
0 
0 
0 


Ralsit 
Falsit 
last 
last 
fast 


last 





fast 


Gn Gul Gal Gal GGG) 


Received 


seconds 
seconds 
seconds 
seconds 
seconds 
seconds 


seconds 


S| 2] cS © 


SS Soe) Oa) =] 





ey sey Se) SF re =) 
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| show policy 


List of Syntax 
Syntax on page 873 
Syntax (EX Series Switches) on page 873 


Syntax 


show policy 

<logical-system (all | logical-system-name)> 
<policy-name> 

<statistics > 


Syntax (EX Series Switches) 


show policy 
<policy-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
statistics option introduced in Junos OS Release 16.1 for MX Series routers. 


Description 


Display information about configured routing policies. 


Options 


none—List the names of all configured routing policies. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


policy-name—(Optional) Show the contents of the specified policy. 


statistics—(Optional) Use in conjunction with the test policy command to show the length of time (in 
microseconds) required to evaluate a given policy and the number of times it has been executed. This 
information can be used, for example, to help structure a policy so it is evaluated efficiently. Timers 
shown are per route; times are not cumulative. Statistics are incremented even when the router is 
learning (and thus evaluating) routes from peering routers. 


Required Privilege Level 
view 
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RELATED DOCUMENTATION 


show policy damping 


test policy 


List of Sample Output 

show policy on page 874 

show policy policy-name on page 875 

show policy statistics policy-name on page 875 


Output Fields 
Table 23 on page 874 lists the output fields for the show policy command. Output fields are listed in the 
approximate order in which they appear. 


Table 23: show policy Output Fields 


Field Name Field Description 
policy-name Name of the policy listed. 
term Name of the user-defined policy term. The term name unnamed 


is used for policy elements that occur outside of user defined 


terms 
from Match condition for the policy. 
then Action for the policy. 


| Sample Output 


show policy 


user@host> show policy 


Configured policies: 





__vrf-export-red-internal__ 





__vrf-import-red-internal__ 
red-export 
rf-test-policy 


multicast-—scoping 


show policy policy-name 


user@host> show policy vrf-import-red-internal 





Policy vrf-import-red-internal: 
from 
Z0 BO ls 0/23 mmaceep es 
205, 0,113 ,S32/28 accep 


then reject 


show policy statistics policy-name 


user@host> show policy statistics iBGP-v4-RR-Import 


Policy iBGP-v4-RR-Import: 
[1243328] Term Lab-Infra: 
from [1243328 0] proto BGP 
[28 ©] womies sea iiceies 
10.11.0.0/8 orlonger 
10.13.0.0/8 orlonger 
then [28 0] accept 
[1243300] Term External: 
from [1243300 1] proto BGP 
[1243296 0] community Ext-Coml [64496:1515 ] 
[1243296 0] prefix-list-—filter Customer-Routes 
[1243296 0] aspath AS6221 
LL BZAS2S il] wowice iEuilieeies 
LIZ AG 490/12 oiclomeaie 
LIZ AG.50 0/12 @iciloiaetere 
LIZ AG,51 0/2 oicloineere 
I 2G 2 0)/ ie wor longer 
IN 2G 5 610)/ 12 Sor longelr 
172716.6050/12 orlonger 
then [1243296 2] community + Ext-Com2 [64496:2000 ] [1243296 
[4] Term Final: 

















then [4 0] reject 


0] 


accept 
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| show route 


List of Syntax 
Syntax on page 876 
Syntax (EX Series Switches) on page 876 


Syntax 


show route 

<all> 

<destination-prefix> 

<logical-system (all | logical-system-name)> 
<private> 

<te-ipv4-prefix-ip te-ipv4-prefix-ip> 
<te-ipv4-prefix-node-ip te-ipv4-prefix-node-ip> 
<te-ipv4-prefix-node-iso te-ipv4-prefix-node-iso> 


<rib-sharding (main | rib-shard-name)> 


Syntax (EX Series Switches) 


show route 


<all> 
<destination-prefix> 
<private> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

Option private introduced in Junos OS Release 9.5. 

Option private introduced in Junos OS Release 9.5 for EX Series switches. 

Command introduced in Junos OS Release 15.1R3 on MX Series routers for enhanced subscriber 
management. 

Option display-client-data introduced in Junos OS Release 16.2R1 on MX80, MX104, MX240, MX480, 
MX960, MX2010, MX2020, vMX Series routers. 

Options te-ipv4-prefix-ip, te-ipv4-prefix-node-ip, and te-ipv4-prefix-node-iso introduced in Junos OS 
Release 17.2R1 on MX Series and PTX Series. 

rib-sharding option introduced in cRPD Release 20.1R1. 


Description 


Display the active entries in the routing tables. 


Options 


none—Display brief information about all active entries in the routing tables. 
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all—(Optional) Display information about all routing tables, including private, or internal, routing tables. 
destination-prefix—(Optional) Display active entries for the specified address or range of addresses. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


private—(Optional) Display information only about all private, or internal, routing tables. 


display-client-data —(Optional) Display client id and cookie information for routes installed by the routing 
protocol process client applications. 


te-ipv4-prefix-ip te-ipv4-prefix-ip—(Optional) Display IPv4 address of the traffic-engineering prefix, without 
the mask length if present in the routing table. 


te-ipv4-prefix-node-ip te-ipv4-prefix-node-ip—(Optional) Display all prefixes that have originated from the 
traffic-engineering node. You can filter IPv4 node addresses from the traffic-engineered routes in the 
Isdist.0 table. 


te-ipv4-prefix-node-iso te-ipv4-prefix-node-iso—(Optional) Display all prefixes that have originated from 
the traffic-engineering node. You can filter IPv4 routes with the specified ISO circuit ID from the 
Isdist.O table. 


rib-sharding (main | rib-shard-name)—(Optional) Display the rib shard name. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Understanding IS-IS Configuration 
Verifying and Managing Junos OS Enhanced Subscriber Management 


List of Sample Output 

show route on page 881 

show route (VPN) on page 882 

show route (with Destination Prefix) on page 882 
show route destination-prefix detail on page 883 
show route extensive on page 883 


Output Fields 


Table 24 on page 878 describes the output fields for the show route command. Output fields are listed in 
the approximate order in which they appear. 
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Table 24: show route Output Fields 


Field Name 


routing-table-name 


number destinations 


number routes 


destination-prefix 


Field Description 


Name of the routing table (for example, inet.0). 


Number of destinations for which there are routes in the routing table. 


Number of routes in the routing table and total number of routes in the following states: 


e active (routes that are active). 


e holddown (routes that are in the pending state before being declared inactive). A holddown 
route was once the active route and is no longer the active route. The route is in the 
holddown state because a protocol still has interest in the route, meaning that the interest 
bit is set. A protocol might have its interest bit set on the previously active route because 
the protocol is still advertising the route. The route will be deleted after all protocols withdraw 
their advertisement of the route and remove their interest bit. A persistent holddown state 
often means that the interested protocol is not releasing its interest bit properly. 


However, if you have configured advertisement of multiple routes (with the add-path or 
advertise-inactive statement), the holddown bit is most likely set because BGP is advertising 
the route as an active route. In this case, you can ignore the holddown state because nothing 
is wrong. 


If you have configured uRPF-loose mode, the holddown bit is most likely set because Kernel 
Routing Table (KRT) is using inactive route to build valid incoming interfaces. In this case, 
you can ignore the holddown state because nothing is wrong. 


e hidden (routes that are not used because of a routing policy). 


Route destination (for example:10.0.0.1/24). Sometimes the route information is presented 
in another format, such as: 


e MPLS-label (for example, 80001). 
e interface-name (for example, ge-1/0/2). 


e neighbor-address:control-word-status:encapsulation type:vc-id:source (Layer 2 circuit only. For 
example, 10.1.1.195:NoCtrlWord:1:1:Local/96): 


e neighbor-address—Address of the neighbor. 


e control-word-status—Whether the use of the control word has been negotiated for this 
virtual circuit: NoCtrlWord or CtrlWord. 


e encapsulation type—Type of encapsulation, represented by a number: (1) Frame Relay 
DLCl, (2) ATM AAL5 VCC transport, (3) ATM transparent cell transport, (4) Ethernet, (5) 
VLAN Ethernet, (6) HDLC, (7) PPP, (8) ATM VCC cell transport, (10) ATM VPC cell 


transport. 
e vc-id—Virtual circuit identifier. 


e source—Source of the advertisement: Local or Remote. 


Table 24: show route Output Fields (continued) 


Field Name 


[ protocol, preference 


] 


weeks:days 
hours:minutes:seconds 


metric 


localpref 


from 


Field Description 


Protocol from which the route was learned and the preference value for the route. 


e +—A plus sign indicates the active route, which is the route installed from the routing table 
into the forwarding table. 


e -—A hyphen indicates the last active route. 


e *—An asterisk indicates that the route is both the active and the last active route. An asterisk 
before a to line indicates the best subpath to the route. 


In every routing metric except for the BGP LocalPref attribute, a lesser value is preferred. In 
order to use common comparison routines, Junos OS stores the 1's complement of the LocalPref 
value in the Preference2 field. For example, if the LocalPref value for Route 1 is 100, the 
Preference2 value is -101. If the LocalPref value for Route 2 is 155, the Preference2 value is 
-156. Route 2 is preferred because it has a higher LocalPref value and a lower Preference2 
value. 


How long the route been known (for example, 2w4d 13:11:14, or 2 weeks, 4 days, 13 hours, 
11 minutes, and 14 seconds). 


Cost value of the indicated route. For routes within an AS, the cost is determined by the IGP 
and the individual protocol metrics. For external routes, destinations, or routing domains, the 
cost is determined by a preference value. 


Local preference value included in the route. 


Interface from which the route was received. 
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Table 24: show route Output Fields (continued) 


Field Name 


AS path 


encapsulated 


Route Labels 


validation-state 


to 


Field Description 


AS path through which the route was learned. The letters at the end of the AS path indicate 
the path origin, providing an indication of the state of the route at the point at which the AS 
path originated: 


e I-IGP. 
e E—EGP. 
e ?—Incomplete; typically, the AS path was aggregated. 


When AS path numbers are included in the route, the format is as follows: 


e []—Brackets enclose the local AS number associated with the AS path if more than one AS 
number is configured on the routing device, or if AS path prepending is configured. 


e {}—Braces enclose AS sets, which are groups of AS numbers in which the order does not 
matter. A set commonly results from route aggregation. The numbers in each AS set are 
displayed in ascending order. 


e ()—Parentheses enclose a confederation. 


e ([])—Parentheses and brackets enclose a confederation set. 


NOTE: InJunos OS Release 10.3 and later, the AS path field displays an unrecognized attribute 
and associated hexadecimal value if BGP receives attribute 128 (attribute set) and you have 
not configured an independent domain in any routing instance. 


Extended next-hop encoding capability enabled for the specified BGP community for routing 
IPv4 traffic over IPv6é tunnels. When BGP receives routes without the tunnel community, 
IPv4-Over IPvé tunnels are not created and BGP routes are resolved without encapsulation. 


Stack of labels carried in the BGP route update. 


(BGP-learned routes) Validation status of the route: 


e Invalid—Indicates that the prefix is found, but either the corresponding AS received from 
the EBGP peer is not the AS that appears in the database, or the prefix length in the BGP 
update message is longer than the maximum length permitted in the database. 


e Unknown-—Indicates that the prefix is not among the prefixes or prefix ranges in the database. 


e Unverified—Indicates that the origin of the prefix is not verified against the database. This 
is because the database got populated and the validation is not called for in the BGP import 
policy, although origin validation is enabled, or the origin validation is not enabled for the 
BGP peers. 


e Valid—Indicates that the prefix and autonomous system pair are found in the database. 
Next hop to the destination. An angle bracket (>) indicates that the route is the selected route. 


If the destination is Discard, traffic is dropped. 
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Table 24: show route Output Fields (continued) 


Field Name Field Description 


via Interface used to reach the next hop. If there is more than one interface available to the next 
hop, the interface that is actually used is followed by the word Selected. This field can also 
contain the following information: 


e Weight—Value used to distinguish primary, secondary, and fast reroute backup routes. 
Weight information is available when MPLS label-switched path (LSP) link protection, 
node-link protection, or fast reroute is enabled, or when the standby state is enabled for 
secondary paths. A lower weight value is preferred. Among routes with the same weight 
value, load balancing is possible. 


e Balance—Balance coefficient indicating how traffic of unequal cost is distributed among 
next hops when a routing device is performing unequal-cost load balancing. This information 
is available when you enable BGP multipath load balancing. 

e Isp-path-name—Name of the LSP used to reach the next hop. 

e label-action—MPLS label and operation occurring at the next hop. The operation can be pop 
(where a label is removed from the top of the stack), push (where another label is added to 
the label stack), or swap (where a label is replaced by another label). For VPNs, expect to 
see multiple push operations, corresponding to the inner and outer labels required for VPN 
routes (in the case of a direct PE-to-PE connection, the VPN route would have the inner 
label push only). 


Private unicast (Enhanced subscriber management for MX Series routers) Indicates that an access-internal 
route is managed by enhanced subscriber management. By contrast, access-internal routes 
not managed by enhanced subscriber management are displayed with associated next-hop 
and media access control (MAC) address information. 


balance Distribution of the load based on the underlying operational interface bandwidth for equal-cost 
multipaths (ECMP) across the nexthop gateways in percentages. 


| Sample Output 


show route 


user@host> show route 


inet.0: 11 destinations, 12 routes (11 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


ESOS SOO ea hOmOm OnraO240) 
MWA / TO) ASeSse4ail, meetse2 iL 
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Indirect 
IEG SSO ORs OR OR One OV/-274.0 
“[RES/LIO] I9eS3o29, iho@alljorer 100, teem 10.0.0. 30 
IMS) joel 1 
STOO n0m24 AR vac t—0)/3)/ One Ayala ol swamchedspathnm to) 
[BEL/LIO)|) IPeSse26, iecallomeic 100, ice 10.0.0,33 
INS) jOeiclag I 
PaeOm Om Om 244 veloute 04s Ome el clock Ss wanechiec pain to.) 
IEG SS OOREE MOOR ORC 0)/-274.0 
“[BELS/ LO) IGsS3o29, ike@alljower 100, iteom 10.0.0. 30 
INS jowiclag I 
STOO MUmZicmnomvelcunkts— 0/2) Ome cy micloch swainchec Sodtunutom 
[BES/LIO]| IMeSsaz25, iecalloresic 100, ice 10.0.0.38 
ASmpatc hier 
Seto LOM On Zon ceva lt—0)/3/0n2s) babel Swarched path tor 


show route (VPN) 
The following sample output shows a VPN route with composite next hops enabled. The first Push operation 


corresponds to the outer label. The second Push operation corresponds to the inner label. 


user@host> show route 192.0.2.0 


13979:665001.inet.0: 871 destinations, 3556 routes (871 active, 0 holddown, 0 
hidden) 
+ = Active Route, Last Active, * = Both 








19250 ,2,0/24 [BCE AGO OO ASE 27 hOCarliorachauels0] Ol mu iara@ mime O neo neo ey 46,0) 
AS path: 13980 ?, validation-state: unverified 
> to 10,100,042 wae ae2.0, Puisia 16, Pusin SOOSGs) (teers) 
[REL/LIO|] WOezS32e, ieyeailsieeic OO, icmonn 10.8).9.16% 
AS path: 13980 ?, validation-state: unverified 
> to 10.100.0.42 via ae2.0, Push 126016, Push 300368 (top) 
# [Multipath/255] 00:28:28, metric2 102 
> co 10,100,042 waa ae2.0, Pusia 16, Pusin SOOSG:s (ees) 
tO 10,100,042 waa ae2.0, Busin 16, wusin SOW S68 (ices) 











show route (with Destination Prefix) 


user@host> show route 192.168.0.0/12 
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inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 


ORG SEO Oral e\Seciede/'s || Zyékel WAgs4ie 27 
S ce 192.168.167.254 wie tego). 0 


show route destination-prefix detail 


user@host> show route 198.51.100.0 detail 


inet.0: 15 destinations, 20 routes (15 active, 0 holddown, O hidden) 
198,51 LOO. O/24 (2 Coieimkss, 2 isieverbincercl)) 
*BGP Preference: 170/-101 





BGP-Static Preference: 4294967292 
Next hop type: Discard 
Address: 0x904lae4 





Next-hop reference count: 2 





State: <NoReadvrt Int Ext AlwaysFlash> 
Inactive reason: Route Preference 

Local AS: 200 

Age: 4d 1:40:40 

Validation State: unverified 

MESS IRI 

Announcement bits (1): 2-BGP_RT_Background 
AS) joaiclag 4 B © i 


show route extensive 


user@host> show route extensive 


vi.mvpn.0: 5 destinations, 8 routes (5 active, 1 holddown, 0 hidden) 
LEGSHSOO SZ ISI) OO .40/240 Cl eiteiey, iL ecimveiumeccl) 
* BGP Preference: 170/-101 
PMS b lags 0x0 sbabels 0200: PiM—sM Sender sO 0-0F 40) Group 20S. OR i3sr il 





Next hop type: Indirect 
Address: 0x92455b8 





Next-hop reference count: 2 
SOUBC Cran Ol Or Ors0) 
Protocol next hop: 10.0.0.40 


Indirect next hop: 2 no-forward 
State: <Active Int Ext> 

Local AS: 64510 Peer AS: 64511 
Age: 3 Metric2: 1 





Validation State: unverified 
Resist aes GEmo4 osiO Pe ORO ROR Si Orsa7/,9) 
Announcement bits (2): O-PIM.vl 1-mvpn global task 
INS) jotting i (Oreiwealiasieor)) Cilustece liste  10.0,0.30 
AS path: sOnigunaton lp: 0 0n 040 
Communities: target:64502:100 encapsulation:0L:14 
Import Accepted 
Localpref: 100 
Romicere Ie 10.00.30 
Primary Routing Table bgp.mvpn.0 
Indirect next hops: 1 
DACQEOCOIL mesic Imoss LO .0.0.,40 Wieieiene@s A 
Indirect next hop: 2 no-forward 
Indirect path forwarding next hops: 1 
Next hop type: Router 
Next hop: 10.0.24.4 via 1t-0/3/0.24 weight 0x1 
HOMO MO 4 01/325 Orelciinat ine sRie nets 


Metric: 1 Node path count: 


Forwarding nexthops: 1 
Nexthop: 10.0.24.4 via 1t-0/3/0.24 
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| show route instance 


List of Syntax 
Syntax on page 885 
Syntax (EX Series Switches and QFX Series) on page 885 


Syntax 


show route instance 

<brief | detail | summary> 
<instance-name> 

<logical-system (all | logical-system-name)> 
<operational> 


Syntax (EX Series Switches and QFX Series) 


show route instance 
<brief | detail | summary> 
<instance-name> 


<operational> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Display routing instance information. 


Options 


none—(Same as brief) Display standard information about all routing instances. 


brief | detail | summary—(Optional) Display the specified level of output. If you do not specify a level of 
output, the system defaults to brief. (These options are not available with the operational keyword.) 


instance-name—(Optional) Display information for all routing instances whose name begins with this string 
(for example, cust1, cust11, and cust111 are all displayed when you run the show route instance cust1 
command). 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


operational—(Optional) Display operational routing instances. 
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Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Transporting IPv6 Traffic Across IPv4 Using Filter-Based Tunneling 
Example: Configuring the Helper Capability Mode for OSPFv3 Graceful Restart | 320 


List of Sample Output 

show route instance on page 887 

show route instance detail (VPLS Routing Instance) on page 888 
show route instance operational on page 888 

show route instance summary on page 888 


Output Fields 
Table 25 on page 886 lists the output fields for the show route instance command. Output fields are listed 
in the approximate order in which they appear. 


Table 25: show route instance Output Fields 


Field Name Field Description Level of Output 
Instance or instance-name Name of the routing instance. All levels 
Operational Routing (operational keyword only) Names of all operational routing — 

Instances instances. 

Type Type of routing instance: forwarding, I2vpn, no-forwarding, All levels 


vpls, virtual-router, or vrf. 


State State of the routing instance: active or inactive. brief detail none 
Interfaces Name of interfaces belonging to this routing instance. brief detail none 
Restart State Status of graceful restart for this instance: Pending or detail 

Complete. 
Path selection timeout Maximum amount of time, in seconds, remaining until graceful | detail 


restart is declared complete. The default is 300. 


Tables Tables (and number of routes) associated with this routing brief detail none 


instance. 


Route-distinguisher Unique route distinguisher associated with this routing instance. | detail 


Table 25: show route instance Output Fields (continued) 


Field Name 
Vrf-import 
Vrf-export 


Vrf-import-target 
Vrf-export-target 


Vrf-edge-protection-id 


Fast-reroute-priority 


Restart State 


Primary rib 


Active/holddown/hidden 


| Sample Output 


show route instance 


Field Description 


VPN routing and forwarding instance import policy name. 


VPN routing and forwarding instance export policy name. 


VPN routing and forwarding instance import target community 


name. 


VPN routing and forwarding instance export target community 


name. 


Context identifier configured for edge-protection. 


Fast reroute priority setting for a VPLS routing instance: high, 
medium, or low. The default is low. 


Restart state: 


e Pending:protocol-name—List of protocols that have not yet 
completed graceful restart for this routing table. 


e Complete—All protocols have restarted for this routing table. 


Primary table for this routing instance. 


Number of active, hold-down, and hidden routes. 


user@host> show route instance 


instance Type 


Primary RIB 


Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


brief none summary 


All levels 


Active/holddown/hidden 


master forwarding 
inet .0 16/0/1 
iso.0 1/0/0 
mpls.0 0/0/0 
inet6.0 2/0/0 


IAAL Swe . 0) 


0/0/0 


887 


__juniper_privatel__ forwarding 
__juniper_privatel__.inet.0 
__juniper_privatel__.inet6.0 


show route instance detail (VPLS Routing Instance) 


user@host> show route instance detail test-vpls 


test-vpls: 
Romce~ IDS O-0,0.0 
Type: vpls State: Active 
Interfaces: 

1si.1048833 

1si.1048832 

fe-0/1/0.513 

ReOwES—Chigitimemagineies 10,255.37 .659 i 





WlEt-ampOrt, || _ WeAt—uMorc—cest—yols—imeermai | 





WLE-GOrER || _ Wetter —cest—yols—imeermal | 
Vrf-import-target: [ target:300:1 ]J 
Vrf-export-target: [ target:300:1 ] 





12/0/0 
1/0/0 


Vf as thet 10 (0 [— onl © aL) OA 10) OO) 0 ees 0 I-N o ofan MPEG I! REN <i - U9 Obes a HALO) UI Ul — ta Oh au Oh anon are oe pol 


Tables: 





test-vpls.12vpn.0 : 3 routes (3 active, 


show route instance operational 


user@host> show route instance operational 


Operational Routing Instances: 
master 


default 


show route instance summary 


user@host> show route instance summary 


Instance Type Primary rib 
master forwarding 
inet .0 
iso.0 


mpls.0 


0 holddown, O hidden) 


Active/holddown/hidden 


15/O/1. 
1/0/0 
35/0/0 
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BGP-INET 





BGP-L 


L2VPN 


LDP 


OSPE 


RIP 


SIVA 


WAEIE 


Weir 


1l2vpn 


WAEIE 


WAEIE 


Waeie 


WAGIE 


13vpn.0 
inet6.0 
12vpn.0 


ILACAL eS wae, 0) 





BGP-INET.inet.0 





BGP-INET.iso.0 
BGP-INET.inet6.0 











BGP-L.inet .0 
BGP-L.iso.0 

BGP lemp dese) 
BGP-L.inet6.0 


L2VPN.inet .0 
L2VPN.iso.0 

L2VPN.inet6é.0 
L2VPN.12vpn.0 





LDP.inet.0 
LDP.iso.0 
LDP.mpls.0 
LDP.inet6.0 





ILD , WA SaLIeewsAE 6 (0) 


OSPF.inet.0 
OSER ESO 
OSPF.inet6é.0 


RIP.inet.0 
RIP.iso.0 
RIP.inet6.0 





SIAN IS g aiovere 5 O 





ao 


IC. 15050 
SrA le aa ctor 0 











0/0/0 
2/0/0 
0/0/0 
0/0/0 


5/0/0 
0/0/0 
0/0/0 


5/0/0 
0/0/0 
4/0/0 
0/0/0 


0/0/0 
0/0/0 
0/0/0 
2/0/0 


4/0/0 
0/0/0 
0/0/0 
0/0/0 
0/0/0 


7/0/0 
0/0/0 
0/0/0 


6/0/0 


0/0 
0/0 


4/0 


/0 
/0 


/0 


0/0/0 





0/0 


/0 
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| show route protocol 


List of Syntax 
Syntax on page 890 
Syntax (EX Series Switches) on page 890 


Syntax 


show route protocol protocol 
<brief | detail | extensive | terse> 


<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show route protocol protocol 
<brief | detail | extensive | terse> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

ospf2 and ospf3 options introduced in Junos OS Release 9.2. 

ospf2 and ospf3 options introduced in Junos OS Release 9.2 for EX Series switches. 
flow option introduced in Junos OS Release 10.0. 

flow option introduced in Junos OS Release 10.0 for EX Series switches. 


Description 


Display the route entries in the routing table that were learned from a particular protocol. 


Options 
brief | detail | extensive | terse—(Optional) Display the specified level of output. If you do not specify a 
level of output, the system defaults to brief. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


protocol—Protocol from which the route was learned: 


e access—Access route for use by DHCP application 

e access-internal—Access-internal route for use by DHCP application 
e aggregate—Locally generated aggregate route 

e arp—Route learned through the Address Resolution Protocol 


e atmvpn—Asynchronous Transfer Mode virtual private network 
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e bgp—Border Gateway Protocol 


ccc—Circuit cross-connect 


direct—Directly connected route 


dvmrp—Distance Vector Multicast Routing Protocol 


esis—End System-to-Intermediate System 


flow—Locally defined flow-specification route 


frr—Precomputed protection route or backup route used when a link goes down 


isis—Intermediate System-to-Intermediate System 


Idp—Label Distribution Protocol 


I2circuit—Layer 2 circuit 


I2vpn—Layer 2 virtual private network 


local—Local address 


mpls—Multiprotocol Label Switching 


msdp—Multicast Source Discovery Protocol 


ospf—Open Shortest Path First versions 2 and 3 


ospf2—Open Shortest Path First versions 2 only 


ospf3—Open Shortest Path First version 3 only 


pim—Protocol Independent Multicast 


rip—Routing Information Protocol 


ripng—Routing Information Protocol next generation 


rsvp—Resource Reservation Protocol 


rtarget—Local route target virtual private network 


static—Statically defined route 


tunnel—Dynamic tunnel 


vpn—Virtual private network 


NOTE: EX Series switches run a subset of these protocols. See the switch CLI for details. 


Required Privilege Level 
view 
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RELATED DOCUMENTATION 


show route | 876 
show route detail 
show route extensive 


show route terse 


List of Sample Output 

show route protocol access on page 892 

show route protocol arp on page 892 

show route protocol bgp on page 893 

show route protocol direct on page 894 

show route protocol frr on page 894 

show route protocol Idp on page 895 

show route protocol ospf (Layer 3 VPN) on page 896 
show route protocol rip on page 896 


Output Fields 


For information about output fields, see the output field tables for the show route command, the show 
route detail command, the show route extensive command, or the show route terse command. 


| Sample Output 


show route protocol access 


user@host> show route protocol access 


inet.0: 30380 destinations, 30382 routes (30379 active, 0 holddown, 1 hidden) 





+ = Active Route, - = Last Active, * = Both 
13.160 .0.3/ 32 *[Access/13] 00:00:09 

SiO 13,160,0.2 wile 26-0/0/0.0 
13), 160.0 ,4/ 32 * [Access/13] 00:00:09 

> t© 13.160.0.2 wie %e-0/0/0.0 
13.150 ,0.5/ 32 * [Access/13] 00:00:09 

2S tO 13,160 ,.0.2 wile 2e-0/0/0.0 





show route protocol arp 


user@host> show route protocol arp 


inet.0: 


licitem or 


Guls tele citey Os 


43 destinations, 


3 destinations, 


1033 des 








+ = Active Rout 


2O 20.1, 3/32 


ZlOr 
Z0r 
AO. 
AD. 
Zr 
2) 6 
2D. 
Z0r 
AD. 


AO. 


show route protocol bgp 


20% 


Ze 


20% 


20% 


208 


20% 


20% 


Ze 


Z0% 


Z0F 


-4/32 


oa 32 


50/32 


oI 3Z 


5 Ot 32 


sO 32 


NOS 2 


MAL 32 


12/32 





13/32 


, 


ARP/4294 


ARP/4294 


ARP/4294 


ARP/4294 


3 routes 


tinations, 


Unusabl 


Unusabl 
ARP / 4294967293 


Unusabl 


Unusabl 
ARP/ 4294967293 
Unusabl 
ARP/ 4294967293 


Unusabl 


Unusabl 


43 routes 


Last Active, 


DT ADS) 
S 
DSTA) 3) 


e 


e 
KOTAS) 3) 


e 


S 


S 


DTA) 


© 





ARP/4294 








ARP/4294 





Unusabl 
ARP/ 4294967293 
Unusabl 
ARP/ 4294967293 


Unusabl 


DTA 3) 


e 


e 


e 
NOTA 3) 





Unusabl 


eS 


(42 active, 


* 





(3 active, 


2043 routes 
Both 


0 holddown, 


00:04:35, 


00: 


00: 


00: 


00: 


00: 


00: 


00: 


00: 


00: 


00: 


04: 


04: 


04: 


04: 


04: 


04: 


04: 


04: 


04: 


04: 


35, 


By 


34, 


35, 


35, 


35, 


35, 


33, 


33, 


33, 


user@host> show route protocol bgp 192.168.64.0/21 


inet.0: 


335832 destinations, 








+ = Active Rout 


192.168 64 ,0/ 21 


, 


* [BGP/170] 
AS path: 


335833 routes 


Last Active, 


* 


0 holddown, 


from 


from 


from 


from 


from 


from 


from 


from 


from 


from 


from 


Zr 


Z0F 


Zin 


ZOr 


ZOr 


Ze 


AO. 


Z0F 


20. 


Z0r 


Z0r 


1 hidden) 


0 hidden) 


(GOSS wactiare, 


Z0% 


Z0F 


ZiOks 


20% 


Z0F 


AQ). 


208 


20. 


Zils 


Zi0F 


20% 


(C35e8smacitaivic, 
= Both 


CcleOF Aas: skGr, 
10458 14203 2914 4788 4788 I 


0 holddown, O hidden) 


0 holddown, 450 hidden) 


localsereit 100, teem 192.168 ,69.71 


S te 192.169, 167,254 sve igo). 0 
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show route protocol direct 


user@host> show route protocol direct 


inet.0: 335843 destinations, 335844 routes (335394 active, 0 holddown, 450 hidden) 








+ = Active Route, Last Active, * = Both 

172 5 16 61835 O/ Be *+[Darect/O) l7w0d 10731749 
2 Wile #e-1/3/1.0 

10,255 .,165.1/32 *[Direct/0] 25w4d 04:13:18 
> Wile lov). 

Zeon ORO 24 *[Direct/0] 17w0d 23:06:26 
S Wile we-1/3/2.0 

192 168,164 0/22 *[Direct/0] 25w4d 04:13:20 








> wala i450) 0) 


iso.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 
ATMO OO SMO Bem OO OO CORMOMO Sm OOO OMmO 2p SSG 5 00hle/ao2 
*[Direct/0] 25w4d 04:13:21 


> via 100.0 


inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


AMO geloiess 210s 2558 1656 1/23 
*[Direct/0] 25w4d 04:13:21 
> wila lo.0 
fe80::2a0:a5ff:fel2:ad7/128 
*[Direct/0] 25w4d 04:13:21 


> wie iol, 0 


show route protocol frr 


user@host> show route protocol frr 


inet.0: 43 destinations, 43 routes (42 active, 0 holddown, 1 hidden) 


inet.3: 3 destinations, 3 routes (3 active, 0 holddown, O hidden) 





custl.inet.0: 1033 destinations, 2043 routes (1033 active, 0 holddown, 0O hidden) 
+ = Active Route, Last Active, * = Both 








AD. 20.1 ,3/ 32 [RR 200] OOROSsas, sccm 20.20. 1.1 
> cO Z0,.20.1.3 Wia ce-4/11/0.0 


20,2051 ,4/ 32 S[PRR/ 200] OOSOSsS8, iicm 20.20.10. 
> tO 20,20.1.4 waa ge-4/1/0.0 


20.20 1 57 32 SPAR / 200i) OOSOS2 a5, sccm 20.20. ii 
> tO 20 ,20.1,.5 wia ge-4/1/0.0 





AQ), 20.1 of 32 “PPR /Z00 | OOSOSsS7, wise 2Oo2BO i .i 
StO 20,20. 1.6 waa ge4/11/0.0 


AD. 20,1. 7/32 FERRO Onl mOOmO Stic met ome One Orginal 
> tO 20,20 1.7 wa ge-4/1/0.0 


AO) 20 I gf 32 = [PRR/ ZOO] OOSOSs38, tiem 20.20 1.1 
> tO 20,20.1.8% wia ge-4/11/0.0 


20.20.41. 9/32 = [RR 200i) OOROS2 as, secon 20.20. i. i 
> cO 20.20.1.9 wia ge-4/1/0.0 











20 20,1, 10/32 TTR 200] OOsOSs38, tiem 20.20.11 


show route protocol Idp 


user@host> show route protocol Idp 


inet.0: 12 destinations, 13 routes (12 active, 0 holddown, O hidden) 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 

192.168.16.1/32 2 IND2/S)]| el ZR2O3e35, ameiereske i 
> via t1-4/0/0.0, Push 100000 

G2, 68, LL Se SIND /S)]] tel ZAsO03s35, mmeerese i 





> via t1-4/0/0.0 


privatel__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 


mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








100064 wwe /9]| icl 2SsOSsS5, meirwiLe i 


F© LO lO 15,1 wile ge-0/2/4.0, Pusin 16, Pusin 2SI9792 (ices) 


co LO, 10.151 wile ¢e-O/2/4.0, usin 16, Dusin 2792 (ices) 


FO LO IO 5.1 wha ce-0/2/4.0, Pusin 16, Busia 2EIO792 (cea) 


co 10,10 ,15,1 whe oGe-O0/2/4.0, Pugin 16, Bbisin 27792 (tees) 


E© LOMO 15,1 wile ge-0/2/4.0, Pusin 16, Pusin 29792 (ices) 


co 10,1015. 1 wila cSe-O/2/4.0, Pusin 1G, Desi 2S) 792 (ees) 


tO LO IO 5.1 wie oe-0/2/4.0, Pusin 1G, Pusin 29792 (cea) 


895 


896 


S wie cil-4/0/O.0, Beie 


100064 (S=0) DP / 2] cl 2IsO0segs, mecieae 1 
> waa cil=-4/0/0.0, Poe 
100080 “De / 9] cl 2IsOsesgs, meiciewe 1 





> via t1-4/0/0.0, Swap 100000 


show route protocol ospf (Layer 3 VPN) 


user@host> show route protocol ospf 


inet.0: 40 destinations, 40 routes (39 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 

10.39,1,4/3€ ZOSE Hy /ehOn mm OOnO Orel c meincietaeoneA 
> wala c3=3/2/0.0 

10,39 ,1, 8/36 O©SPH/sOi OOO 5 -sSremmei: neue 


2 Wile b3—3/2/0.0 
10,255.14, 171/32 *(OSPF/10] 00:05:18, metric 4 
= wile 63-3/2/0.0 
10,255.14, 179/32 FAO SER sO me OO Ole Gy amen cites me 

= wile t3-3/2/0.0 

172 ,16,233.,5/ 32 S(OSPr/10]) 20325255, iweieresie: il 

















VPN-AB.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 








10.3951, 16/30 [OSPF/10] 00:05:43, metric 1 

> via so-0/2/2.0 

10,255.14, 173/32 *[OSPF/10] 00:05:43, metric 1 

=> Vila so-0/2/2-0 

172 5G BSS). Sil B2 SOSR2/ 10] 2Oe263 20, mseiaye il 





show route protocol rip 


user@host> show route protocol rip 


inet.0: 26 destinations, 27 routes (25 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 


VPN-AB.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 
10,255,141 7/32 SRP / LOO] Zoecr2acsa. imeiciene 2 
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